« Heavy sigh1000 to build in Rocky Point »

Why doesn't Dejavu provide a "unique" property?


Permalink 03:59:40 pm, by fumanchu Email , 496 words   English (US)
Categories: Dejavu

Why doesn't Dejavu provide a "unique" property?

On c.l.p., Leif K-Brooks wrote:

My ideal solution would be an object database (or object-relational mapper, I guess) which provided total transparency in all but a few places, built-in indexing, built-in features for handling schema changes, the ability to create attributes which are required to be unique among other instances, and built-in querying with pretty syntax.

Dejavu meets a bunch of those needs (transparency, indexing, very pretty querying--no schema change tools though), but my initial reaction to reading his list was to say to myself, "Dejavu doesn't really provide 'attributes which are required to be unique'."

Well, it turns out it does, it's just that they're limited: the 'ID' attribute is the only one which can be required to be unique. They do not need to be globally unique--you could have a Customer object with an ID of 23 and a Purchase object with an ID of 23. But you can't have two Customer objects, each with the same ID of 23.

Well, that's not quite true. Rather than having a ton of explicit guards sprinkled throughout the code, the 'requirement to be unique' is enforced by the fact that Sandboxes will simply overwrite one Unit with another if they have the same ID. It's just that this is done lazily, so far a brief period of time, you could have two objects with the same ID.

  1. Create an instance A, either with or without an ID.
  2. Memorize it.
  3. Create an instance B, explicitly giving it the same ID as A.

When you memorize B, your Storage Manager may allocate space for instance B. But you'll only be able to recall either A or B (provider-dependent).

The other built-in guard is the UnitSequencer, which provides ID values when you don't. If you provide your own ID, then the sequencer doesn't get called. Right now, there are two sequencers:

  • UnitSequencerInteger: this one will supply increasing integers. [hmmm... I should put a mutex in there]
  • UnitSequencerNull: this one just raises NotImplementedError, so you need to always supply your own ID's.

I suppose I could rewrite the Null one to guarantee uniqueness, in order to avoid the corner case I outlined above. I just haven't had the need. I'm a conscientious coder, and haven't needed any more checks than these two.

The final issue for (future) users of Dejavu might be that they need some attribute other than ID to be unique. But I've never run into that, and am reticent to add it unless someone asks for it. So ask, but be prepared to convince me that that's a better approach than redesigning your model, or using a custom StorageManager to fake it, or both.

No feedback yet

Leave a comment

Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
September 2020
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      


The requested Blog doesn't exist any more!

XML Feeds

powered by b2evolution