Archives for: February 2005, 11
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.
- Create an instance A, either with or without an ID.
- Memorize it.
- 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.
Some of our Field Team left yesterday to prepare for groups in Rocky Point (or in Spanish, Puerto Peñasco) next week/weekend. In addition to a number of Arizona churches, we get half-a-dozen Young Life groups. Together, they should build about 40 homes!
Plus the Team Leaders are all meeting off-site. So the office is a bit quieter today...