Discussions

News: The Busy Java Developer’s Guide to db4o

  1. The Busy Java Developer’s Guide to db4o (27 messages)

    An object database like db4o simply has more to offer to object-oriented developers, in today's object-oriented world, than its relational cousins. This article, the second in a series from Ted Neward, explains some of the benefits of an object-oriented database as compared to a relational database. Discussing an object database's query-by-example facility, he explains:
    QBE is the preferred mechanism for simple query situations because it's an easier API to work with, but it does require that your domain objects permit any or all of the fields containing data to be set to null, which may violate some of your domain rules. For example, it would be nice to be able to enforce both a first name and a last name for Person objects. Using Person in a QBE query for just last name, however, mandates that the first name be allowed to be null, which effectively means we either have to choose the domain constraint or the query capability, neither of which is entirely acceptable. Native queries provide a powerful way to execute complex queries without having to learn a new query language or resort to complicated object structures to model a predicate. And for those situations where db4o's native query facility fails to meet the need, the SODA API (which originally appeared as a standalone query system for any object system, and still lives on SourceForge) allows you to tune the query down to its tiniest detail, at the expense of simplicity. This multi-faceted approach to querying databases may strike you as complex and confusing and entirely different from how an RDBMS works. In truth, this isn't quite the case: Most large-scale databases translate SQL text into a bytecode format that is analyzed and optimized and then executed against the data stored on disk, assembled back into text, and returned. The db4o native query approach puts the compilation into bytecode back into the hands of the Java (or C#) compiler, thus allowing for type safety and earlier detection of incorrect query syntax. (Type safety is sadly missing from JDBC's approach to accessing SQL, by the way, because it is a call-level interface and is thus restricted to strings that can only be checked at runtime. This is true of any CLI, not just JDBC; ODBC and .NET's ADO.NET suffer from the same limitation.) Optimization is still done inside the database, but instead of text being returned real objects are sent back, ready for use. This is in marked contrast to the SQL/Hibernate or other ORM approach, which Esther Dyson famously described as follows: Using tables to store objects is like driving your car home and then disassembling it to put it into the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car.

    Threaded Messages (27)

  2. Object database? Yeah... I'll get right on that.
  3. I've been curious about Object-oriented databases for some while now. However there is one thing holding me back: there are none around that have the same name-recognition as Oracle, MySQL et al. So basically, I don't know who to trust. :) A bit curious, what major commercial and open source OODBMS systems are around? And how do they stack up in terms of stability, robustness, resilience and scalability? Object-oriented databases are cool and all, but if I can't trust them with my critical data, and grow with them, they are pretty much useless. / Wille Blog: Buzzword Bingo
  4. DB4O on PDA[ Go to top ]

    Let me do a disclaimer first: these are my experiences and in no way are representative for DB4O on other platforms. I've tried to use DB4O as the embedded database on a PDA using IBM J9 (limited Java 1.3 JVM). The learning curve was acceptable, although it took me some time to get the engine embedded in the application like I wanted. However, the performance was not acceptable and I had hardly any way of determining what the problem was or how to improve it. Since I did not want to burden my little PDA with ORM, and DB4O explicitely states that it is very suited for running on an embedded environment, I invested quite some time in trying to get it to move. Never the less I failed, and switched to HSQLDB using direct JDBC. And this performs very acceptably. So for now my curiousity has been satified.
  5. what major commercial and open source OODBMS systems are around?
    And how do they stack up in terms of stability, robustness, resilience and scalability?
    Object-oriented databases are cool and all, but if I can't trust them with my critical data, and grow with them, they are pretty much useless.blockquote> Well, you asked so forgive if this looks like a sales pitch ;-) The issue with OODB vendors is that their customers kind of view them as secret weapons and generally don't allow to market their use. Upfront ... I work for Versant. Versant is the leading commercial OODB. Public in 1996, and last 6 consecutive records have set profitability records. We were in Business Week as the #1 company in the small cap for 2006 with over 300% growth. Versant is used by: The Largest Options Stock Trading Exchange in the world ( think the most stock trading volume per day in the world at 100K+ Tx/sec ), The largest travel reservations system in the world ( think the biggest airlines in the world ), a major financial news provider ( claims to be largest content provider in the world with 9000 live feeds and over 30+Terabytes of XML content all in Versant), All major telco 3G network providers for their Network Management solutions( think largest equipment providers of UMTS, WCDMA, GPRS ), Govt - satelite based analysis systems ( use your imagination here - or look at one non-classified example CDFSII - Air Force Battle Management Weather Forecasting), several massive multi-player online games (both Govt and commercial), U.S. State Department hazardous material tracking, fraud detection systems, .....the list is very long but illusive due to the nature of the applications that deploy the technology .... generally the most demanding in the world. Most of these systems deploy what we call FTS ( Fault Tolerant Server ). Provides synchronous redundency of transactions that are in-flight recoverable if a data nodes goes down. Don't even need to rollback. Imagine the stock exchange example. They don't know if its a $10 trade or a $10M trade. You can trust us. -Robert
  6. what major commercial and open source OODBMS systems are around?
    And how do they stack up in terms of stability, robustness, resilience and scalability?
    Object-oriented databases are cool and all, but if I can't trust them with my critical data, and grow with them, they are pretty much useless.
    Well, you asked so forgive if this looks like a sales pitch ;-) The issue with OODB vendors is that their customers kind of view them as secret weapons and generally don't allow to market their use. Upfront ... I work for Versant. Versant is the leading commercial OODB. Public in 1996, and last 6 consecutive records have set profitability records. We were in Business Week as the #1 company in the small cap for 2006 with over 300% growth. Versant is used by: The Largest Options Stock Trading Exchange in the world ( think the most stock trading volume per day in the world at 100K+ Tx/sec ), The largest travel reservations system in the world ( think the biggest airlines in the world ), a major financial news provider ( claims to be largest content provider in the world with 9000 live feeds and over 30+Terabytes of XML content all in Versant), All major telco 3G network providers for their Network Management solutions( think largest equipment providers of UMTS, WCDMA, GPRS ), Govt - satelite based analysis systems ( use your imagination here - or look at one non-classified example CDFSII - Air Force Battle Management Weather Forecasting), several massive multi-player online games (both Govt and commercial), U.S. State Department hazardous material tracking, fraud detection systems, .....the list is very long but illusive due to the nature of the applications that deploy the technology .... generally the most demanding in the world. Most of these systems deploy what we call FTS ( Fault Tolerant Server ). Provides synchronous redundency of transactions that are in-flight recoverable if a data nodes goes down. Don't even need to rollback. Imagine the stock exchange example. They don't know if its a $10 trade or a $10M trade. You can trust us. -Robert
  7. Many object databases I've seen are so focused on making your data look like objects that they forget to consider other important features commonly available in an RDBMS. I feel db40 is no exception in this regard. Indexing and query execution plans are probably the most important feature of any RDBMS. In db4o, indexing isn't covered much in the documentation, and it only appears to support one property per index. Unique indexes don't seem to be supported either. Also, if I wanted to evaluate the performance of an index or see which one was selected, I was unable to see any utility that showed a query execution plan. Just because your data is in "objects" doesn't mean these features are no longer needed. While native queries look very cool, there doesn't appear to be any way to tell if your query was "optimized" or not. At least, there's no documented list of rules you must follow. Once I figure out what all the rules are, I'm not writing in "native Java" anymore, but instead a very constrained Java. Essentially, I'm a slave to the query compiler anyhow, so I might as well have a small custom query language instead. Being able to control transaction isolation level is also an important feature that db4o appears to be lacking. Is it lacking because db4o's use of an object model makes such a feature unnecessary? I don't think so. Support for triggers, constraints and auto-increment properties appear to be supported in db4o, but the example code required to use these features looks much more complicated than the RDBMS version. I pretty much gave up on object databases after the ODMG was unable to ever come up with a decent spec. The problem is not the relational model, but instead it's the way we choose to represent it in an OO language. Here's the shameless plug for my framework which represents the relational model in objects: http://carbonado.sourceforge.net/
  8. Lazy loading: db4o+JPOX[ Go to top ]

    I evaluated db4o a while ago and although I liked the performance and avoidance of the 'impedance mismatch dance' you get when persisting to a RDBMS via an ORM I could not bring myself to give up lazy loading - which at that time db4o did not support. I'm not sure if lazy loading is natively supported now by db4o (I doubt it is) but it can be achieved very easily by using recent versions of JPOX: JPOX now supports db4o as one of its datastores. JDO 2 in general, and therefore JPOX, whilst providing excellent, high performance support for RDBMSes, isn't architecturally dependent on a table/row based view of the world so I imagine adding support for an object database like db4o would have been a fairly straightforward and clean implementation effort by the JPOX developers. Given that JDO 2 apps are written to the JDO 2 spec it should be a very easy step to try ripping out an existing RDBMS and plonking in a db4o engine under the hood and taking it for a spin around the block - just be careful you don't get a speeding ticket!
  9. Re: Lazy loading: db4o+JPOX[ Go to top ]

    I could not bring myself to give up lazy loading - which at that time db4o did not support ... I'm not sure if lazy loading is natively supported now by db4o (I doubt it is)
    AFAIK, this is a planned feature and is a couple of releases away. It will be completely transparent: http://tracker.db4o.com/jira/browse/COR-111
  10. Many object databases I've seen are so focused on making your data look like objects that they forget to consider other important features commonly available in an RDBMS.
    If you need a database for other purposes that just persisting an application's data, you probably need a relational database. The advantage of a relational database is it allows data to be retrieved in combinations that you did not consider in your design (albeit not always well.) But I've often put things in the database (or worked with such things) that are not really 'data' but more configuration details that aren't really interesting to any sort of reporting or other application. For example I've seen tables that were merely schedules for batching (don't ask) or tables that configure who gets an email in the case of a certain error. I wonder if it would make sense to use something like an OO database for this kind of thing. Perhaps the added complication and added point-of-failure overwhelm the benefits but it's worth considering, I think.
  11. Many object databases I've seen are so focused on making your data look like objects that they forget to consider other important features commonly available in an RDBMS.


    If you need a database for other purposes that just persisting an application's data, you probably need a relational database. The advantage of a relational database is it allows data to be retrieved in combinations that you did not consider in your design (albeit not always well.)
    [snip...]

    I've worked with OO dbs for many years, and what you say about data retrieval is very, very true. Relational databases support the notion of data independence, where you can optimise the retrieval/querying of your data without having to pre-know/recast the navigation paths in your database. OO dbs are very poor for data reporting.
    however, OO databases can be much faster than relational when you know these paths and you know they won't change. I've had extremely impressive results for CAD applications -- storing drawings and navigating around drawing elements. OO dbs work much better for this often by orders of magnitude.
    An excellent OO database I have used is objectdb (www.objectdb.com). I have no relationship with the company that produces this apart from being a satisfied customer, but its excellent performance and small footprint has astonished me. I also really like the JDO spec for OO dbs, although for relational dbs I can't say. In particular the ability to hold object references between transactions is priceless and something I always found missing in versant.
    I believe that db4o support the ability to hold the data in db40, but synch to a relational db. this has many promising applications where you get the best of both worlds.
    Andrew
  12. I also really like the JDO spec for OO dbs, although for relational dbs I can't say. In particular the ability to hold object references between transactions is priceless and something I always found missing in versant.
    Hi Andrew, Great to see you having success with OODB's. In general, I agree with your comments. It is worth pointing out though that if you develop a model for building adhoc relationship, then OODB's can do data mining very well compared to RDB. As an example, you can read about the 6-degrees of seperation implementation in the U.S. State Departments global hazardous material tracking application a.k.a. Tracker. http://www.afcea.org/awards/awardwinners.html http://www.trackernet.org/ProductInfo/Whitepages/Scalability.pdf Also, Versant for example has ODBC/JDBC drivers that allow you to create an ER representation of your object model and use something like Crystal Reports to do reporting. Albiet, this is not the lightning fast performance you get with using your model and navigation, but works well for basic management reporting. Versant does support, JDO. So, not sure why the comment regarding holding references across transaction boundaries. This works fine. Cheers, -Robert
  13. Versant for example has ODBC/JDBC drivers that allow you to create an ER representation of your object model and use something like Crystal Reports to do reporting. Albiet, this is not the lightning fast performance you get with using your model and navigation, but works well for basic management reporting.

    Versant does support, JDO. So, not sure why the comment regarding holding references across transaction boundaries. This works fine.

    Cheers,
    -Robert
    Well, the caveat is that I haven't used Versant in anger since about 2001. Anyway, at the time you couldn't hold references between units of work. We were constantly having to refresh them. The JDBC/ODBC support (again, 2001) was there, but the performance was abysmal if you needed to join in the opposite direction of an association. I remember that it in effect did the object equivalent of "a full table scan". In addition, with large datasets we constantly ran out of memory. I prefer the JDO interface, certainly compared to db4o's interface and the native versant one. Andrew p.s. Is Kieron McCammon still with Versant? He was our consultant on-site in '99.
  14. I prefer the JDO interface, certainly compared to db4o's interface
    ... so you could use JPOX 1.2 and have a JDO2 (or JPA1) interface and use DB4O underneath ;-) -Andy JPOX - Java Persistent Objects
  15. I prefer the JDO interface, certainly compared to db4o's interface

    ... so you could use JPOX 1.2 and have a JDO2 (or JPA1) interface and use DB4O underneath ;-)

    -Andy
    JPOX - Java Persistent Objects
    definitely sounds like a step in the right direction. Did JPOX used to be the reference implementation in another life or am I thinking of something else. was it hard to do the integration? does it have any significant limitations? Cheers, Andrew
  16. Did JPOX used to be the reference implementation in another life or am I thinking of something else.
    JPOX 1.1 was the RI for JDO 2.0. JPOX 1.2 will be the RI for JDO 2.1
    was it hard to do the integration? does it have any significant limitations?
    The implementation as far as it is currently taken (all persistence operations, getObjectById, getExtent, metadata/annotations, persistence-by-reachability, cascade-delete etc) was straightforward, taking 1-2 weeks effort. The remaining essential work (JDOQL, other query languages) will take longer. The follow-on work catering for DB4O-specific features (allowing for schema upgrade, for example) is not envisaged to take long.
  17. The implementation as far as it is currently taken (all persistence operations, getObjectById, getExtent, metadata/annotations, persistence-by-reachability, cascade-delete etc) was straightforward, taking 1-2 weeks effort. The remaining essential work (JDOQL, other query languages) will take longer. The follow-on work catering for DB4O-specific features (allowing for schema upgrade, for example) is not envisaged to take long.
    I'm surprised that it took so little time. In the version of db4o I used (early last year) it had no persistence by reachability, and no correct optimistic locking on transactions. I can't remember the exact issue but the lack of reachability really turned me off the product. how did you implement this? Andrew
  18. The implementation as far as it is currently taken (all persistence operations, getObjectById, getExtent, metadata/annotations, persistence-by-reachability, cascade-delete etc) was straightforward, taking 1-2 weeks effort. The remaining essential work (JDOQL, other query languages) will take longer. The follow-on work catering for DB4O-specific features (allowing for schema upgrade, for example) is not envisaged to take long.


    I'm surprised that it took so little time. In the version of db4o I used (early last year) it had no persistence by reachability, and no correct optimistic locking on transactions. I can't remember the exact issue but the lack of reachability really turned me off the product.

    how did you implement this?

    Andrew

    Actually, I think it was the complexities around lazy fetching (or whatever it is called in JDO) that caused me problems. For some reason I recall that it had no hollow state, or at least no ability to go from filled to hollow to filled again. Sorry if the terminology isn't right or the details are incorrect -- it's been a while.
    Andrew
  19. I'm surprised that it took so little time. In the version of db4o I used (early last year) it had no persistence by reachability, and no correct optimistic locking on transactions. I can't remember the exact issue but the lack of reachability really turned me off the product.

    how did you implement this?
    The time taken was learning db4o ;-) db4o allows retrieval down to a fetch depth. At that depth object refs are marked as "inactive". JPOX and JDO have the mechanism for traversing object graphs (since we perform reachability for RDBMS stores in the same way), so detecting when an object is non-activated and activate it is trivial. Ties in nicely to JDO2 FetchPlans. Same for updating objects and detach/attach. Regarding moving to "hollow", that can be left to the impl to decide if it wants to null out fields when the txn ends (normally uses "retainValues" property), but db4o also allows you to "deactivate" objects (currently JPOX leaves the values intact). Same for going "hollow" to "persistent-clean" ... activate them if they were deactivated at commit. JPOX - Java Persistent Objects
  20. Regarding moving to "hollow", that can be left to the impl to decide if it wants to null out fields when the txn ends (normally uses "retainValues" property), but db4o also allows you to "deactivate" objects (currently JPOX leaves the values intact). Same for going "hollow" to "persistent-clean" ... activate them if they were deactivated at commit.
    To give more info, JPOX uses StateManagers to handle field loading/unloading. When an object is enlisted in a txn and the txn is committed all fields that are no longer needed (e.g user not specified "retainValues") are nulled and marked as not loaded (hence hollow is supported by JPOX, rather than via anything explicit in DB4O). When enlisting the object back in a txn any fields that are then accessed that are not loaded will be loaded (via going to DB4O and requesting them). So lazy loading etc is a thin layer on top of anything DB4O provides. Similarly optimistic txn checking is handled by JPOXs version checking rather than relying on DB4O to do it ... in the same way as JPOX would do the same for RDBMS. -Andy JPOX - Java Persistent Objects
  21. Is Kieron McCammon still with Versant? He was our consultant on-site in '99.
    No, Keiron has moved on to his own company. He and I are buddies and got about 8 days of snowboarding over this last season. You should checkout his new company. http://www.kaboodle.com Cheers, -Robert
  22. [snip] It is worth pointing out though that if you develop a model for building adhoc relationship, then OODB's can do data mining very well compared to RDB.[snip]
    I remember that versant had decent bidirectional links. if you implement all relationships as bidirectional you get a level of data independence... I miss bilinks -- wish they were in JDO. Andrew
  23. If you need a database for other purposes that just persisting an application's data, you probably need a relational database. The advantage of a relational database is it allows data to be retrieved in combinations that you did not consider in your design
    - db4o supports a variety of on-the fly schema changes to allow for changes and refactorings in the object model. It also provides a way to handle more complicated conversions. - When you use Native Queries in your code, unlike SQL, when you refactor your objects using a decent IDE, the queries get refactored also - since they are written in Java (or C#). - db4o also has a replication feature which can use Hibernate to copy the data into an RDBMS. If you need to integrate with other apps, or do reporting with traditional tools - this is possible.
  24. If you need a database for other purposes that just persisting an application's data, you probably need a relational database. The advantage of a relational database is it allows data to be retrieved in combinations that you did not consider in your design

    - db4o supports a variety of on-the fly schema changes to allow for changes and refactorings in the object model. It also provides a way to handle more complicated conversions.
    - When you use Native Queries in your code, unlike SQL, when you refactor your objects using a decent IDE, the queries get refactored also - since they are written in Java (or C#).
    - db4o also has a replication feature which can use Hibernate to copy the data into an RDBMS. If you need to integrate with other apps, or do reporting with traditional tools - this is possible.
    I'm not sure if this addresses my point or not. The problem area I am referring to is data-warehousing. Most of the clients of our data-warehouse are not developers. We don't have time to modify the schema for every report they might want to run (there could be, and probably are) thousands. If I want to pull in another table into a query in an relational database, I just do it. I might have to get an index added but that's about it. It seems to me that OO databases only allow data to be retrieved as designed. We have a over 6 terabytes of data 1 to 2 of which are surely distinct. I'm not sure how we would manage that with an OO database when we aren't sure what we'll want to pull out of it tomorrow. Perhaps I am mistaken. If this is handled by OO, I'm interested to understand how.
  25. I'm not sure if this addresses my point or not. The problem area I am referring to is data-warehousing. Most of the clients of our data-warehouse are not developers. We don't have time to modify the schema for every report they might want to run (there could be, and probably are) thousands. If I want to pull in another table into a query in an relational database, I just do it. I might have to get an index added but that's about it.

    It seems to me that OO databases only allow data to be retrieved as designed. We have a over 6 terabytes of data 1 to 2 of which are surely distinct. I'm not sure how we would manage that with an OO database when we aren't sure what we'll want to pull out of it tomorrow. Perhaps I am mistaken. If this is handled by OO, I'm interested to understand how.
    Its a difficult question to answer directly because OODB's tend to vary widely in their ability in this area. That being said, I can certainly be done with an OODB. It is more a question of how and the efficiency of the approach. The best way, is to create a model which by design can discover and create new relationships. This has been done by several folks. It's been done by customers of Versant in the military analytics area and others like the FGM Tracker system implementing a 6 degrees of seperation with visualization. It's also been done by others like TeraData, which is not an object nor relational database, uses their own query mechanism, and they have commercialized it with much success. This just illustrates the point that you do not need a relational database to have a world class data warehouse. Another way to do it, which is less efficient, is using the OODB's native query capabilities in some form assuming you've chosen an OODB where they exist. For example, using Versant you have pretty much all the same query capabilities that you have with SQL ....hash,b-tree,compound,agreggate indexes, math operations on predicates, GroupBy, OrderBy, AND, OR, NOT, etc, etc. Even the equivalent of the JOIN, which in OO terms is called a PATH query, so long as the relationship exists in the model ( in essence an intended PK,FK not relationship through arbitrary values ). Versant (Currently) does not have a native JOIN where a relationship does not exist in the model. However, you could use one of our tools that presents the object model in ER form and use a standard SQL tool like Crystal Reports if you really want/need to. Again, it is really about efficiency. Model is best, Native Query capabilities next, add-on tools to "look" like a relational db last. While the 3rd option is clearly inferior to just using an RDB, the 1st option has proven to be superior to using an RDB....as evidenced by the growing demand for Teradata. So, the other question you would need to ask yourself is...what else do I need to do besides mine/report on my data. Because in most cases, that is whats really driving your requirements anyway. For that reason, you often see both solutions in an enterprise .... databases dedicated to application needs and seperate databases dedicated for warehouse/reporting. Often it is simply not possible or practical to combine the two. Cheers, -Robert
  26. Many object databases I've seen are so focused on making your data look like objects that they forget to consider other important features commonly available in an RDBMS.
    True... and I believe stems from the fact that several of the leading OODB vendors where started by OO application developers who wanted a database more seamlessly integrated with their OO languages. However, the key quoted word should be "Many", as some were founded by a team of kernel engineers from existing relational vendors. Versant for example, was founded by a team of Sybase kernel engineers.
    Indexing and query execution plans are probably the most important feature of any RDBMS. ...... if I wanted to evaluate the performance of an index or see which one was selected, I was unable to see any utility that showed a query execution plan.
    Agree, these are the most important feature of an RDBMS, but not necessarily of an ODBMS. I would say that query is a very important feature for nearly all databases, but navigational ability is the "most" important feature for an OODB. So, Versant offers a fully indexed server side query execution engine. You can have b-tree, hash, multiple indexes, aggregate indexes, etc and the query execution engine will make use of the most appropriate given the query context. You have tools that derive statistics showing the impact of execution time, efficiency of indexes, sequential scan time, etc to observe the usefulness of your execution plan. However, Versant also provides for navigational optimizations by giving ways to control use case based loading of the data ( objects ) related to the stuff found in your query. So, you can have simpler queries than might otherwise be necessary in an RDB and the navigation can load accordingly related information .... without having to do the cross-product multiplication required in a relational JOIN. That is where a lot of the OODB efficiency and speed comes into play resulting in a reduced a system footprint by 50-75% ..... think 4 CPUs instead of 16CPUs ...that's a lot better than buying a "green" CPU to reduce the data center power consumption.
    >Being able to control transaction isolation level is also an important feature that db4o appears to be lacking.
    Not missing in Versant, which provides locking at the object level, similar to row locking in RDB. Using locking controls you can control isolation level. Isolation control is critical for multi-user systems, something not readily found in embedded applications which is where db4o gets the most mileage.
    Support for triggers, constraints and auto-increment properties appear to be supported in db4o, but the example code required to use these features looks much more complicated than the RDBMS version.
    Code?? Using Versant you use an admin tool to define triggers. Auto-increment can be useful if you are using identity tied to your data values.... something many modern relational texts warn against. In Versant, identity is managed orthogonally to data values and id's are auto-incremented so you never have to think about them. Constraints, that's another topic all together. Versant chose not to implement constraints in the database. They are expected to be in your model which is the master schema, not some other DDL needed for the database. I think most of the MVC based frameworks have illustrated that constraints are best enforced closest to the offending code as possible. I would hate to see a system design that makes every validation propagate all the way back to the database before failing a constraint check. That being said, I would not argue constraints are not a nice to have feature as a safe guard at the cost of some performance. Cheers, -Robert
  27. Unique indexes don't seem to be supported either.
    - db4o supports unique constraints e.g: config.add(new UniqueFieldValueConstraint(YourClassHere.class, "fieldName"))
    While native queries look very cool, there doesn't appear to be any way to tell if your query was "optimized" or not. At least, there's no documented list of rules you must follow
    - db4o allows the developer to register diagnostic listeners, you can then tune into events such as "NativeQueryNotOptimized" - Comprehensive documentation on this and everything else is bundled with db4o and also online here: http://developer.db4o.com/Resources/view.aspx/Reference
    Being able to control transaction isolation level is also an important feature that db4o appears to be lacking.
    - db4o provides full ACID transactions with read-committed isolation. There are no other isolation levels currently supported (AFAIK), but this seems to suit a wide range of applications.
    Support for triggers, constraints and auto-increment properties appear to be supported in db4o, but the example code required to use these features looks much more complicated than the RDBMS version.
    - See example above for establishing a unique constraint. Does that look hard? - The equivalent of triggers in db4o are standard Java event listeners and they're not complicated at all. Hands up - who would prefer to write triggers in Java?
    Here's the shameless plug for my framework
    ;-)
  28. Re: Some more info[ Go to top ]

    Brian, just want to clarify on some of your points:
    In db4o, indexing isn't covered much in the documentation, and it only appears to support one property per index.

    Indexing is covered here:
    http://developer.db4o.com/Resources/view.aspx/Reference/Db4o_Database_Management/Indexing
    http://developer.db4o.com/Resources/view.aspx/Reference/db4o_Database_Management/Performance_Tuning/Enable_Field_Indexes
    db4o does not have multi-field index API, instead one should use indexes on all queried fields. I think it would be correct to compare indexing functionality having RDBMS and db4o benchmark results, otherwise one can't say that indexing implementation in db4o is not sufficient.
    Unique indexes don't seem to be supported either.

    Unique indexes are supported in version 6.2:
    http://developer.db4o.com/Resources/view.aspx/Reference/Advanced_Db4o_Techniques/Unique_Constraints
    This feature is new and does not have unique indexes over several fields - this is work in progress. However, you can easily implement it yourself - the following example shows how to implement a unique constraint over all the fields of an object:
    http://developer.db4o.com/Resources/view.aspx/Reference/Advanced_Db4o_Techniques/External_Callbacks/Commit-Time_Callbacks/Committing_Event_Example
    While native queries look very cool, there doesn't appear to be any way to tell if your query was "optimized" or not.

    There is a way:
    http://developer.db4o.com/Resources/view.aspx/Reference/db4o_Database_Management/Diagnostics/NativeQueryNotOptimized
    Support for triggers, constraints and auto-increment properties appear to be supported in db4o, but the example code required to use these features looks much more complicated than the RDBMS version.


    I think it depends on personal preferences - I do not see anything difficult in callbacks. Moreover this way gives you freedom to realize any arbitrary behavior.