>> Not really AFAIK: The ability to not have to manage fetch depths that >> JDO/DB40 gives you over raw DB40 gives you is a massive productivity >> boost (not sure if the latest DB40 supports lazy loading or not yet). > >This is OT, but I feel it needs some correction. > >DB4O has had transparent activation (automatic loading of references if/ >when needed) and transparent persistence (automatic update depth) for a >while now. You byte code can even be automatically instrumented with TA/TP >(but note code injection doesn't work with Scala, so we hand-code a few >base relationship classes with TA instead).
That's good to know. I evaluated DB40 a few years ago but the lack of support for automatic activation/lazy loading of references if/when needed really took away from my concept of the *ideal* transparent, object database solution and so scared me off. I took it up with the DB40 developers and they were adamant that 'no automatic/lazy loading' was an intentional design strategy and a good thing - which freaked me out a bit, making me believe DB40 would never get something I judged to be so essential for any transparent persistence solution - glad to see they've 'seen the light' on automatic activation now. Using JDO/DataNucleus, with its automatic activation, over the top of DB40 was a sneaky way of achieving that - as well as the datastore agnosticism that brings. >You are also missing out on advantages like automatic schema updates, >DB4O's own unique ID system, and other very useful parts of the DB4O API. The way I use JDO I get all of those features but in a datastore agnostic way. For unique IDs I make sure I use the default long int OIDs. I also make sure I use unique IDs for the discriminators and avoid the default 'package/class name' discriminator (otherwise you class info into your datastore which is an inhibitor to refactoring). We use Javelin MDA (www.visualclassworks.com) to generate unique discriminators and all meta data for us so there's zero effort in making our models persistent capable. >> In any case coding to a standard persistence interface (JDO) >> over a proprietary API is IMHO an insurance policy > >I can understand that, and I think that way too in some situations, but I >reject the notion that there is no price to pay. We certainly haven't paid any price in terms of developer productivity by using JDO because with byte code enhancement the persistence is truly transparent. Perhaps there might be a slight run time performance advantage in using DB40 direct instead of JDO over DB40 (if we went that way eventually) but at this stage the performance is exceptional with JDO over MySQL and it has rock solid reliability with a huge enterprise app with 952 classes. Our app will definitely be using an object database one day in the future and that's why we chose JDO instead of other persistent frameworks that cement the future of our apps into 1970's RDBMS technology - none of us want that :) Is DB40 starting to get used more in the enterprise world now? A few years ago it was very popular in the embedded market (BMW use it in the on board car computers!) but its use in large enterprise apps was unclear. Hopefully that's changed now also. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
