After playing around with a variety of approaches I am leaning towards using shared primary keys as you suggest in this post.
However with that said I have a few questions:
Avoiding primary key collisions
In my case the superclasses are rarely known too far in advance. For example initially groups and users were distinct with no shared class, but later features such as commenting mean that they are both now "authors" or "identities" and need to share a superclass. Unfortunately there are collisions between the primary keys, so I can't use shared primary keys in a backwards compatible way.
For this reason I was considering using a single source of keys that are unique DB-wide. I am leaning against GUIDs due to how insane they would be in URLs or to speak aloud. With that in mind I am considering just a simplistic rerolling random number generator. A DB-wide sequence also seems workable, although I don't like how predictable and scrapeable the id's would be.
I was curious how reasonable of an approach this is, and also what the best general approach was for implementing it. I was considering a universal superclass Object table, or perhaps a separate non-table system that generates and keeps track of these id's (similar to how a sequence works).
How to model this in Persistent/Esqueleto
It seems like I'm probably going to use some external SQL and some manual conversion functions between subclass primary keys and superclass primary keys. However it does seem like I have to do quite a lot of outside intervention and would prefer if there was a nicer approach.
It may be worth including answers to the above in the blog post, or if not I'd still greatly appreciate what you have to say about them. Thanks!
After playing around with a variety of approaches I am leaning towards using shared primary keys as you suggest in this post.
However with that said I have a few questions:
Avoiding primary key collisions
In my case the superclasses are rarely known too far in advance. For example initially groups and users were distinct with no shared class, but later features such as commenting mean that they are both now "authors" or "identities" and need to share a superclass. Unfortunately there are collisions between the primary keys, so I can't use shared primary keys in a backwards compatible way.
For this reason I was considering using a single source of keys that are unique DB-wide. I am leaning against GUIDs due to how insane they would be in URLs or to speak aloud. With that in mind I am considering just a simplistic rerolling random number generator. A DB-wide sequence also seems workable, although I don't like how predictable and scrapeable the id's would be.
I was curious how reasonable of an approach this is, and also what the best general approach was for implementing it. I was considering a universal superclass
Object
table, or perhaps a separate non-table system that generates and keeps track of theseid
's (similar to how asequence
works).How to model this in Persistent/Esqueleto
It seems like I'm probably going to use some external SQL and some manual conversion functions between subclass primary keys and superclass primary keys. However it does seem like I have to do quite a lot of outside intervention and would prefer if there was a nicer approach.
It may be worth including answers to the above in the blog post, or if not I'd still greatly appreciate what you have to say about them. Thanks!