MVCSoft today announced the release of its JDO Toolkit, Enterprise Edition. The JDO Toolkit includes a GUI Workbench, Ant and XDoclet support, and an advanced runtime with caching, dynamic load policies, user-defined data transformations and more.
It provides support for all the required JDO features and most optional features.
- read/write transactional cache
- the ability to add user-defined functions to the JDO query language
- dynamic load policies with unlimited nesting and smart SQL generation
- multiple configurable strategies to manage large result sets
- user defined transformations of data
- normalized relationship mappings for maps, collections, and arrays.
It comes with 200 pages of documentation and all the source code to the product, for only $139.
so how does your product compare to Hibernate?
I really appreciated the quality of your CMP implementation - although I never got to really using it. I remember the extensive and insightful documentation in particular. Hibernate is still hard to beat, however..
There's no question that Hibernate is an excellent product that has proven itself in many settings. If it were a proprietary product, I'd point out the value of a standards-based product, but frankly an open-source product with a large user base has many of the same advantages. Also, from some things I've read on TheServerSide I'm hopeful that JDO and Hibernate may be able to come together in the not-too-distant future.
MVCSoft and Hibernate provide similar value propositions. You get the source code with both products, and for most people there is no difference between free (as in beer) and $139. I'm sure Hibernate has features that MVCSoft doesn't and vice versa. I'll try to get a chance to write up a comparison if people think this would be valuable. On the other hand, I've never seen a feature matrix from a vendor that included a lot of categories where the competitor got check marks and they didn't. If an independent third party wants to volunteer to write up a comparison I'd be happy to provide them with a copy of the software, and any assistance they need.
MVCSoft has a GUI Workbench along with the standard Ant and XDoclet tools. Some people will appreciate this. Of course, a lot of TheServerSide's readers are Ant and XDoclet loyalists, and a GUI is almost an anti-selling point to them. I prefer Ant and XDoclet too, but it's nice to be able to configure complicated data structures like load policies in the GUI, and cut-and-paste them into XDoclet tags. It's also nice to be able to browse your generated project, double-check your XDoclet tags, or test something quickly without setting up an entire project.
One important feature of the MVCSoft JDO Toolkit is the ability to define load policies for eager loading of data. I don't think that Hibernate currently provides this to the same extent, but I'd also like to point out I'm not a Hibernate expert. I'd like to expand on this feature in some detail.
Many programmers know about the "n+1" problem from entity EJBs with bean-managed persistence. A finder query returns only the keys for the beans in the result set. Subsequent calls to the ejbLoad life-cycle method create an additional query for each key in the original result set. The total number of queries is 1 (for the keys) + n (number of beans), instead of one query. Obviously, this is VERY BAD. "n+1" is not just an EJB problem--it is a general problem in translating from relational database tables to objects. A data retrieval task that should (in relational terms) take one or two queries, instead takes n+1 queries where n is the number of controlling objects.
In other object/relational mapping tools, this is typically encountered with collection classes mapped to related tables in the relational schema. Each object in the query result might lazily load its own collection class, resulting in the original query plus n additional queries where n is the number of JDO objects. This "n+1" inefficiency can cascade through your multi-valued relationships, increasing the number of queries exponentially.
Let's consider an example with three objects and two relationships: customer has orders, and orders have line items. A typical scenario is as follows:
1) A query returns a set of ten customers.
2) Each customer has placed ten orders, which are lazily loaded when a collection is accessed.
3) Each order has some varying number of line items, which are also lazily loaded when a collection is accessed.
In this scenario, there are 1+10+100 queries (111 queries) issued to the database. One is for the original query; ten are for the order collections for each customer; and one hundred are for the line items for each order object. That's a lot of queries. In a program that dealt with relational constructs directly, the total number of queries would be three: one for the customers, one for the orders, and one for the line items.
The difference between the scenario with 111 queries and the scenario with 3 queries is *information.* When you use JDBC directly, you are applying your knowledge of your application to load exactly what you need all at once (sometimes known as "eager loading"). When you use an O/R tool, its runtime doesn't know anything about your application that you don't tell it. As a result, it needs to guess how much of an object's state and relationships to pull in at one time. Typically, this guess doesn't extend to related objects--because once you start pulling in related data, you could end up loading the entire database into memory for a transaction that just wants to get the customer's name. If you end up using the related data, it will be loaded at that time (aka "lazy loading").
If you tell the MVCSoft runtime what data you'll be needing, it can do just as good a job at loading the data as you can. For our example, if you specify a load policy to the MVCSoft JDO runtime when you issue the query, all the data you need will be eagerly loaded in exactly three queries.
The MVCSoft JDO Toolkit provides for load policies (aka fault groups) that can define arbitrary data sets and navigate unlimited levels of related data. There are two types of fault groups available to MVCSoft JDO Toolkit users: static and dynamic.
Static fault groups are useful when you know the data that needs to be loaded at design time. One advantage of static definitions is that you can use a vendor's toolset to create them. Another advantage is that the runtime can do "one time" initialization on startup, rather than after the fault group is created in code. (With the MVCSoft JDO product, static fault groups can be specified with XDoclet tags or defined in the MVCSoft JDO GUI Workbench. Fault group configurations can have a lot of nested data, so even if you use XDoclet, it can be useful to define your fault groups in the GUI and then cut and paste the generated XML into an XDoclet class tag.)
Dynamic fault groups are necessary when the required data changes. An example of this might be an application screen that displays the results from an end-user-defined query. With the MVCSoft JDO product, dynamic fault groups can be created programmatically through an API.
By the way, thanks for the question and the kind words about the MVCSoft PM.
Hibernate supports eager fetching and/or lazy loading in mappings and at runtime, in both the HQL and Query By Criteria. But MVCSoft looks like a better deal (the $140 are per developer) than some of the other options.
This is an exciting product for me. I worked with MVC's EJB solution and found it to work wonderfully well. Not only did the product do everything quickly, but development was quite easy. I also found that the documentation was quite extensive, with lots of examples and details.
I can see some of the issues from the EJB CMP product (the load plans, optimizations, etc.) are carried over here, which implies that this has the same solid core as the CMP product.
I also have to give top marks on support. They were always very quick to answer email and questions, and issue patches on any problems very quickly.
I am a very happy hibernate user, but for people looking for this sort of product, its well worth your time to check out their products.
So what databases do you support? DB2, Oracle, MySQL??
The toolkit supports any database with a JDBC driver. Many features or optimizations require support for left join syntax (either ANSI or Oracle style), which most databases support. The isEmpty() method in the JDO Query Language requires the database to support subqueries, which again is hardly ever a problem.
Is there an evaluation version available? We are currently evaluating several
JDO implementations and would like to evaluate MVCSoft.
I'm happy to let anyone evaluate the full and unlimited version of the software for as long as they need. Please just e-mail me directly at ejbpm at mvcsoft dot com, and I'll give you the download information.