[Nitro] Og::Store (was Re: og regarding legacy apps table hints)
deb at ysabel.org
Fri Aug 19 02:39:24 EDT 2005
George Moschovitis wrote:
> Please try to follow the Og coding conventions, ie:
> - leave a blank line after the comments before each method.
> - try to make all lines <= 64 chars (but don't go out of the way to
> acomplish this, some
> longer lines are ok)
I was trying to, mostly. I figure I can tweak a bit before it becomes
official, but I did change my usual editor settings. (I'd missed the thing
about blank lines after comments, though even if I'd caught it I'd still
probably add that in later as it annoys me. *grin*)
I can definitely shorten a few lines here and there, I haven't been putting
that much focus on making sure I kept it shorter than 80 chars.
> I don't like the name device, isn't device just a store?
Initially I was headed towards Device representing purely low-level stuff
and Store being the go-between between a Device and the upper layers of Og.
Stores represent the idea of CRUD etc on objects and present a clean
interface, and Devices do the low-level translation of objects into and out
of device-specific bits for Stores.
It didn't work out to be quite so seperate, but I haven't yet gone back and
changed the names to Store again. I still have this sense that a Store and
a Device cooperate but given that I can't pin down the distinction, they
should just be Stores at this point. I just haven't gotten to it.
One goal I had is that an object could be persisted in multiple stores
without any bad interactions, thus the pulling all the low-level metadata
out of the class itself and putting it into a device/store-specific
repository indexed by class. However, type selectors and auto-added primary
keys still have to get added to the class itself for the interface to be at
all sane. This is fine if anything that adds either a type selector or a PK
follows the same standards (i.e. uses either Structured* or possibly a PK*
thing that might end up a superclass again) but it also means that if you
store such an object into a Store/Device that doesn't need them, you'll end
up storing them anyway. Not sure how to fix that (or even whether it's
really all that important).
BTW, I really need a better name than "autogenerated_key" for something that
uses AUTO_INCREMENT/SERIAL/SEQUENCE, because I kept having to remind myself
that "autogenerated_key" _doesn't_ mean the oid property we just added, it
means the values stored in the key. And if I kept having to remind myself
while I was writing the stuff that implemented it, it'll confuse people, so
I'm open to any clear suggestions for terms for the two concepts that keep
'em obviously seperate. (Confused further, of course, by the fact that the
oid key that we add is set to use AUTO_INCREMENT et al by default. *grin*)
> I would also like to see some none-sql store abstraction.
The KirbyBase implementation is off of StructuredDevice/StructuredTable
rather than the Sql* classes. Structured* is for anything that has a
table/field-like structure, and in fact I was thinking about tossing in an
XML-based flatfile representation off of Structured*, since that'd be pretty
trivial at this point. (The KirbyBase implementation, which was quite a bit
more work than the MySQL implementation (which took me about 15 minutes),
still only took me ~2 hours. Though it could use some work in a few places,
but even so...) I figure that between an XML flatfile, Kirby and the SQL
stuff, I'll have a good feel for where I have things pushed too far down in
the inheritance tree.
I'm open to ideas about a representation that wouldn't qualify as
Structured*, because I'm sure there are things there that could get split
out and end up in some class between Device and StructuredDevice, but I
couldn't think of anything offhand.
See also my comments in the WISHLIST (I think?) about wanting an abstract
expression of find/update/etc conditions. Kirbybase's approach of using
Ruby is cool but I'm not sure I want to try to build a general ruby->SQL
clause converter. I'm willing to build a quick abstraction of the basic
things you'd see in normal condition clauses, since that's pretty simple,
but I'm also open to more ideas there, as it's something I looked at and
went, "Oooh, big, affects people a lot, I'll stay over here for right now,
(Admittedly, all of this code is colored by my work on Hibernate/JBoss/EJB3;
please do point out places where I'm suffering from blind spots if you see
'em. That's an open invite to anyone on the list, too, btw, not just George.)
[ deb at ysabel.org ] - Ysabel - [ http://www.ysabel.org/ ]
More information about the Nitro-general