-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 27, 2005, at 2:08 PM, James Britt wrote: > Likewise for autopersisted objects. It might be nice if one could > just use objects and have them magically saved/loaded with no > special consideration from the coder, but since it has a real cost, > the coder benefits from having at least some indication that this > is what is happening. So, putting the metadata in the class > definition is Good and Helpful because it alerts the coder to > special conditions. It also makes more clear when some attributes > are to be saved and others are transient. You hit the nail on the head here, James. Persisting objects to a relational database has repeatedly and raucously denied pixie dust treatment. If giving an inch means a simple table <-> class ORM can take us a mile, we should meditate on the nature of pragmatism. >> In addition, my memory of Og is that it encourages thinking in >> database terms (like "has_many") -- true or not? > > Interesting. I don't see "has_many" as being database-centric, > just a means for referring to some form of a relationship that can > occur with or without any persistence mechanism. But maybe I've > just become immune to the effects of certain words and phrases. While terminology like has_many is not restricted to db-think, it is most commonly found there. Fowleresque ActiveRecord ORMs encourage a similar pattern of thought: their metadata are clearly relational hints sitting in your class, so it feels like you're mapping database - -> objects in your head as you develop your app. This is very different from composing a domain model, coding it up, then devising a mapper to persist your object graph. As far as I know there are no Ruby ORM that attempt this. Having done it both ways, I prefer those little hints. The apparent cost of a generic domain mapper is deceptively low due to the "it seems nice" discount, but its true cost is far higher: high conceptual overhead, difficult mapping bugs, and carpal tunnel. > rubyhacker / gmail.com wrote: >> What I want is: >> 1. To think in object (and persistence) terms, not database terms. >> 2. To specify the minimum information necessary in order to marshal >> each of my types. >> 3. To store the metadata separately from my classes/objects so as to >> minimize impact on them. (But probably not in a separate file.) >> Does that make any sense? For deeper satisfaction, look at how Smalltalkers have done it. Why introduce the R and M to O at all? jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDYVxsAQHALep9HFYRApV/AKCcfOZYwXHpzddB9/bvbRzR1c3tLgCgpeJn XdqzF9f9/nRKYu19KEKe/5Y= =fbcX -----END PGP SIGNATURE-----