Re: Flamewar object databases vs. relational databases (was: Unknown SQL)
Date: Mon, 04 Jun 2001 16:38:35 GMT
Message-ID: <fQOS6.25279$Be4.8426833_at_news3.rdc1.on.home.com>
"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.
- 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?
- 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?
- 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 - 18:38:35 CEST