Re: Flamewar object databases vs. relational databases (was: Unknown SQL)

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:9f99i2$d2d$01$2_at_news.t-online.com...

  Sorry to jump in here...

  I've long been a believer that mapping the db into the OO is the way to go. Well as long as I've been using it anyway, which is 100% of the projects since I discovered it about two years ago.

  The product I'm using is EOF. It's currently a part of WebObjects, currently at Apple. This maps the Java objects via a text file onto the JDBC data source. It has the advantage of using traditional db's under it, although of course there's a speed hit during the translation. Luckily I've found the speed hit is typically considerably less than writing my own bad code. Along with that goes the massive developer time savings.

  I have a couple questions for you. Or they might be suggestions.

1. does your product understand changes on a per-field basis, and allow for a real "undo" type stack? For instance, if I change the name of a person, and later change the address, can it see these as two operations? What if I do them at the same time, does it then see it as one operation?
2. when doing rollbacks, does it do a re-fetch? Or does it call the accessor with the "anti-data"? IE, if I change my first name and then undo, does it call the first name accessor with the old first name, or does it invalidate the object for a re-fetch?
3. does your product support cache-coherency between application instances? If I change my name on one copy, do other instances of the program notice this change?

Maury

p.s. you should run a spell checker on your page(s) Received on Mon Jun 04 2001 - 11:38:35 CDT