From: dhtapp Date: 2004-01-09T04:06:41+09:00 Subject: Re: Database applications and OOness I've been watching this thread with a great deal of interest. I'm relatively new to Ruby, and have no experience with the various db approaches (well, except for playing with pstore for a few hours). But I did use NeXT/Apple's EOF product for a few years. I thought I'd just post a few remarks in case any of you gurus are trying to strategize something. That framework used a model object (an EOModel), with which the application communicates directly. The model itself used vendor-free semantics to describe standard database ops, and then the app loaded an appropriate adaptor (EOOracleAdaptor, EOSybaseAdaptor) at runtime to translate the join and fetch requirements into a particular vendor's SQL flavor. In the model, Entities (think tables) could be specified to return either instances of specific Java classes (and earlier, Objective-C classes), or dictionaries. The dictionaries were basically hashes, but they shared the ability with the custom Java classes to respond to key-value coding for fetching and traversal, so that a "keypath" like "someVendor.principalContact.phoneNumber" behaved the same, whatever the type of object loaded. (Note: Apple relied heavily enough on key-value coding and keypath notation to obtain at least one patent on it. I suppose someone looking to implement from the ground up would blow past that pioneering effort and look straight at OGNL, or somesuch.) The model had some support for groupings, and custom read-write statements could be recorded in the model on a per-attribute basis, to override the model's default SQL generation. For instance, you could model two Entities on an invoice table, say "Invoice", which did the standard CRUD stuff, and "InvoiceSummary", which had a couple of standard attributes and a custom reader defined as "sum %amount_due%" (sorry, can't remember the specific syntax, but you get the idea). And there are/were some other nifty ideas. For instance, a "fault" system (much easier for the product engineers to implement in the earlier versions, since Obj-C instances can be coerced into swizzling their own class pointers at runtime...the Java version, from what I understand, took the midnight sacrifice of multiple chickens to come together). Anyway, the idea was that objects fetched from the db would know just enough about themselves to be able to identify (actually, lie about) their Entity types and locate the rest of their data in db. Then, they'd stay dormant until touched for the first time, at which point they'd swap in their correct class information and fetch their individual underlying rows. (That, too, could obviously be a performance problem, but the system provided "batch faulting" and other ways to tune for that.) As my dear (but long-winded) great uncle used to say, "I said all of that to say this:" Anyone thinking of doing this kind of stuff from the ground up could maybe profit from a few weeks' study of the EOF architecture. No need to buy the product; I think there are ample whitepapers up at the Apple site to give an overview of the system. And, given Ruby's runtime dynamics (compared even to Obj-C, to say nothing of Java), and the caliber of folks who hang out here, I have no doubt someone could put together a Clean, Lean Persistence Machine ;-) -dan "Tim Bates" wrote in message news:20040108060053.GG742@bates.id.au... > The point I'm > trying to make is I'd like the system to be able to handle this sort of > query _as_well_as_ the "SELECT * FROM table WHERE property = ?" type > return-a-list-of-objects query. I don't know of any system that can do > that, or even if it could be done neatly. Possibly such a system would > have to accept two sorts of query and handle both separately, but that > introduces its own ugliness. > >