Discussions

News: EJB 3.0 and JDO 2.0: Views from both sides

  1. EJB 3.0 and JDO 2.0: Views from both sides (259 messages)

    Gavin King recently wrote an entry discussing EJB 3.0 where he discussed his thoughts on JDO. Abe White of Solarmetric has posted a response to his comments, and has given TSS permission to post them.

    Firstly you may want to read Gavin's blog on EJB 3.0
    JDO FUD by Abe White

    In his blog, Gavin King of Hibernate recently posted his thoughts on EJB 3. In the second half of his essay, Gavin attempts to justify the EJB 3 expert group's decision to develop their own POJO persistence solution (based on Hibernate and tied to relational databases) rather than adopting JDO.
    Gavin states that there are three problems "right at the heart of the JDO spec" that make it unsuitable for an ORM persistence solution:
    JDOQL, field interception, and specification complexity. Let's examine each in turn:

    1. JDOQL

    Gavin refers to JDOQL as "an abomination". He doesn't back up this claim with evidence or examples, so unfortunately we'll have to talk about JDOQL in a general sense rather than refute any specific arguments.

    JDOQL consists of Java boolean expressions and Java field traversals.
    Boolean expressions are used to form the equivalent of SQL's WHERE and HAVING clauses. Field traversals are used to form the equivalent of SQL's SELECT, GROUP BY, and ORDER BY clauses. Basically, if you know Java, then you know JDOQL. It is difficult to see how this constitutes
    an "abomination". But rather than take our word for it, let's look at
    an example:
    Query q = pm.newQuery (Employee.class);
    q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");

    We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.
    Presumably this company is about to force some retirements :). The query orders the results by the employee id number. If we had wanted to, we could have left out the setResult call and just gotten Employee objects back rather than individual field values. Or we could have used setResult, possibly in combination with setGrouping, to perform aggregations.

    The equivalent query in HQL is:
    Query q = ses.createQuery ("select emp.firstName, emp.lastName, emp.department "
       + "from Employee as emp "
       + "where emp.age > 50 and emp.retired = false and emp.department.name = 'Marketing' and size(emp.projects) = 0 "
       + "order by emp.employeeId asc");

    We won't turn Gavin's contention on its head and say that HQL is "an abomination". It isn't. But it is a little less obvious to the average Java developer, and the fancier the query, the less obvious it becomes (the above example is a very simple one). Some might prefer HQL to JDOQL, but that's all it is: a matter of preference. Others prefer JDOQL to HQL. A vendor could easily create both HQL and JDOQL front-ends to JDO queries; functionally, they are more or less equivalent. This seems a little odd, since according to Gavin, JDOQL represents a problem "right at the heart of the JDO spec".

    Finally, it is worth noting that both EJB 3 and JDO 2 allow direct SQL queries.

    2. Field Interception

    Gavin's second complaint about JDO is that it's use of field
    interception is "a completely inappropriate way to implement POJO
    persistence". He gives only one reason for this blanket assessment:
    "The biggest problem rears its head when we combine lazy association
    fetching with detached objects. In a proxy-based solution, we throw an
    exception from unfetched associations if they are accessed outside the
    context of the container. JDO represents an unfetched association using
    null. This, at best, means you get a meaningless NPE instead of a
    LazyInitializationException. At worst, your code might misinterpret the
    semantics of the null and assume that there is no associated object.
    This is simply unnacceptable, and there does not appear to be any way
    to fix JDO to remedy this problem, without basically rearchitecting
    JDO."

    This statement is, in fact, totally false. JDO 2 will throw an
    exception when attempting to retrieve unfetched values from a detached
    object. It will not return null. It acts exactly like Gavin thinks a
    proper detachment strategy should. And we did not "rearchitect" JDO to
    accomplish this; JDO 2 is 100% backwards compatible, with a grand total
    of one rarely-used operation from JDO 1.0 being deprecated.


    3. Complexity

    Gavin's final complaint is about complexity. "The JDO spec is just
    absurdly over-complex." He provides three concrete examples:
    a. JDO defines four identity types, "where one would do".
    First, one of the four JDO identity types -- nondurable identity -- is
    an optional part of the specification that is meant to support
    persistent objects that don't need unique identities: things like
    persistent log messages. As it is optional and is used to solve a
    problem that EJB 3 persistence cannot solve, it hardly seems fair to
    include it as a sign of JDO's complexity over EJB 3.

    So we're down to 3 identity types. These are: datastore identity
    (identity value managed by the persistence service), application
    identity (identity value managed by the application; i.e. primary key
    fields), and simple identity. Simple identity is just a special case
    of application identity in which there is only one primary key field.

    Interestingly, Hibernate has all three of these identity types as well
    (though datastore identity in Hibernate has limitations). But since
    this is "absurdly complex", and "one would do", we're curious as to
    which two of these three identity types Gavin plans on removing from
    Hibernate.

    b. JDO defines "umpteen lifecycle states and transitions, when there
    should be just three states (persistent, transient, detached)".
    You can group all of JDO's lifecycle states into the three above
    categories, and in fact these categories are all the user ever has to
    be aware of. The JDO authors, however, felt a user might want to be
    able to distinguish between, say, an object that will be inserted on
    flush (persistent-new state), vs. one that will be deleted
    (persistent-deleted), vs. one that will be updated (persistent-dirty),
    vs. one that is persistent, but hasn't changed in the transaction
    (persistent-clean). We don't know about you, but that seems like
    useful information to us. And you can't get it from the three states
    of persistent, transient, and detached.

    The distinction between states not only provides the developer with
    useful information, but also means that most JDO implementations don't
    have to do field-by-field comparisons when deciding what objects to
    flush to the data store. The implementation knows at all times exactly
    which objects are dirty, and exactly which fields in those objects need
    flushing. For transactions involving many objects, this is clearly an
    advantage.

    c. JDO is "bloated with useless features such as 'transient
    transactional' instances".
    First of all, transient-transactional objects are an optional part of
    the JDO spec. They can be completely ignored by users who don't have a
    need for them, and by implementations who don't think their users will
    benefit from them.

    Second, transient-transactional instances can actually be useful. They
    are non-persistent objects that have the ability to rollback their
    state when a transaction is rolled back. This ensures that if you make
    changes to non-persistent state that are only valid if the transaction
    commits, those changes don't come back to haunt you if the transaction
    rolls back for some reason. You can also mix persistent,
    transient-transactional, and unmanaged fields in the same object. Is
    this useful to everyone? No; that's why it's optional. But is it
    useful to some? Certainly.

    Conclusions

    It is disappointing to read the amount of misinformation and downright
    FUD being spewed against JDO. Gavin may simply have been confused on
    certain points; that is perfectly excusable. Passing off confusion as
    fact is slightly less so, but still completely understandable.
    Research takes time that is often in short supply. But the consistency
    and volume of rhetoric from certain vendors with a vested interest in
    tying persistence to EJB and relational databases cannot all be
    attributed to ignorance.

    JDO provides, today, a standardized transparent persistence solution.
    Relational JDO vendors support, today, all of the features found in
    other ORM solutions. JDO 2 will build on this by providing a
    transparent persistence solution that is completely backwards
    compatible, continues to support non-relational stores, and yet also
    standardizes ORM and other relational features, all before EJB 3. Many
    JDO vendors are already previewing JDO 2 features in their products.
    Please, let's base future discussions on facts, not FUD.

    Threaded Messages (259)

  2. But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.
    Ok, it looks very cool. How DBA can tune it ?
  3. But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.
    Ok, it looks very cool. How DBA can tune it ?
    A DBA will never look into the Java code. He/she will probably monitor to the statements executed on the DB. Depending on the JDO implementation the SQL statements may differ.

    A Java developer can easily write down this JDOQL statement. But a Java developer may not be able to tune it. You can find a lot of these developers for developing the application's business logic.

    What you need is one JDO expert in the team of Java developers, who knows how the JDO implementation works and who closely works with DB experts to tune the application. He must review the code and the OR-mapping of the other developers.

    What you finally get is a highly maintainable application. Non-JDO-expert developers can easily understand and extend it. But don't forget the JDO export during the development phase.
  4. The tools should get better[ Go to top ]

    "How DBA can tune it ?"

    Juozas,

    Fair question, but one that is hardly unique to JDO implementations. The answer is that the DBA needs tools. The JDO implementations can provide some of these tools (and some of them are doing that.)

    Abe postulates, in his example, that the older marketing types without projects identified in the query will be offered early retirement. Perhaps instead the query ran (I won't say where) to find people who would like to end their careers by taking on the thankless and pointless task of explaining how EJB 3.0 is better than JDO 2.0. :)

    Most developers will use the tool that does the job with minimum fuss. I happen to think that JDO takes care of persistence with ease in many scenarios and will get better with the 2.0 spec. But I'm quite willing to allow others to have their opinions.

    I'm glad to hear that EJB 3 plans to address the shortcomings of EJB 1, EJB 1.1, and EJB 2. I'm also glad to hear that open source (JBoss and Hibernate) have gained influence in the EJB expert group. Only good can come from these developments. The entire world of software development will change because of the open processes, lean management structure, and agile development of open source. I wish the JBG and the Hibernate team good luck as they lead the charge into the heart of the kingdom of darkness. I'll hazard that they'll need friends before they are done.


    David Ezzio
  5. A Question or Practicality[ Go to top ]

    I think it's clear that Hibernate currently has an edge as a persistence technology not because it is more correct or better designed than any other solution, but rather because of it's practicality. Hibernate is free to use, there is great documentation, a large user community, and a SQL like query language. Is a SQL like query language the best choice for querying persistent objects? Maybe not, but most developers who interact with databases already know SQL and can hit the ground running with HQL.

    That said, I'm all for the changes in EJB 3.0. If they make good on POJO persistence that isn't tied too deeply in all the J2EE services, it will be great. Anyone working in the J2EE space just doesn't use entity beans, or they use them sparingly. The lightweight persistence solutions (OR mapping and JDO) are easier to develop and easier to use.

    On the topic of JDO, my observation is it's just not a technology I can employ today. Though I like the idea of a standardized persistence technology, JDO 1 isn't the path of least resistance. From what we've heard on JDO 2 (http://www.theserverside.com/news/thread.tss?thread_id=25695), I'm not sure how well that's going either.

    I guess what I'm saying is that I need something that I can put to work now. The solution needs to be: Easy to use, easy to learn, and solve the problem. Of all the systems I've used or evaluated (EJB Entity Beans, Apache OJB, JDO, Hibernate, custom code), Hibernate delivers.

    I think the real friction between Hibernate and JDO is a a larger friction between Open Source Java projects and standardization efforts. What we're seeing in the Open Source space is projects that solve a well defined problem and blossom (XDoclet, Hibernate, etc). In the standardization sphere the emphasis is on complete coverage of a set of related problems and creating specifications that allow for several implementations. At the end of the day we need to come together on this one. I want a standardized persistence API and I want a system that solves my problems right now.

    The reality is that the solutions that are more widely used have the edge regardless of what's the best model to get the job done. Will a JDO spec matter if developers continue to adopt O/R packages? Considering that Hibernate is surging in use right now, I think the JDO group should take a serious look at how Hibernate operates because I don't want to end up with an official JDO standard and a de-facto standard.
  6. But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.
    Ok, it looks very cool. How DBA can tune it ?
    I don't know hibernate or any of the JDO packages well enough to say how it is handled. On large financial projects, the DBA's tend to lock down the database and developers do not have access to write stored procedures. Many companies require that all queries go through the DBA, so that every single query is tested and profiled. For small projects with less than 10-15 million rows of data, it's probably ok to let the developers just write the queries. But when the database contains 100million+ rows of data, profiling the queries and creating views to optimize read queries is very important.
  7. Good question, I'd like to know too[ Go to top ]

    But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.
    Ok, it looks very cool. How DBA can tune it ?
    I don't know hibernate or any of the JDO packages well enough to say how it is handled. On large financial projects, the DBA's tend to lock down the database and developers do not have access to write stored procedures. Many companies require that all queries go through the DBA, so that every single query is tested and profiled. For small projects with less than 10-15 million rows of data, it's probably ok to let the developers just write the queries. But when the database contains 100million+ rows of data, profiling the queries and creating views to optimize read queries is very important.
    Any wonder applications are so expensive to develop and maintain? The problem is trying to code in a OO world and persist in a relational. Nothing is 100% (yet) and so something has to give. ORM tools are a great middle ground. From what I've seen, the queries generated are as good as a DBA will write (we had ours looked at).
  8. How banks implement Queries[ Go to top ]

    On large financial projects, the DBA's tend to lock down the database<snip>
    Banks like to compartmentalize things. They get developers to use named queries (supported directly by JDO 2.0) but they facade invocation of the query by their own query factory. This query factory runs locally (not remotely) and it knows to delegate to the underlying named query in most cases - pure delegation. But it also knows that in one or two particular instances, specific named queries are invoked in a "special" way, usually involving a stored proc or custom SQL and perhaps combined with elements of object model navigation.

    In JDO 2.0 the "special" query may still be executed as SQL through the javax.jdo.Query API, and the result is the same persistent objects that would have been retrieve using the named query without "special" treatment; just make sure that the requisite primary key fields are part of the select.

    Alternatively, if you wanted just field values and not persistent objects, that's supported through the aggregation and projection capabilities of the Query interface. And if you don't want an Object[] of fields per returned row from your projected query, just set the query result to an instance of your own custom JavaBean and you'll get one of those per returned row instead. Each of these permutations is supported by the named query capability, and each can have its usual implementation subverted through interception by a Query factory.

    The approach described above works without vendor lock-in but does require some homegrown infrastructure. The alternative is to implement a plug-in for your JDO implementation to achieve the same end - less effort overall but a lock-in to the vendor's plug-in architecture.

    Alternatively, if all you want to do is substitute SQL for the JDOQL of a named query, you can merely alter the query metadata to be SQL-based.

    That is how banks approach the issue.
  9. that makes sense[ Go to top ]

    Banks like to compartmentalize things. They get developers to use named queries (supported directly by JDO 2.0) but they facade invocation of the query by their own query factory. This query factory runs locally (not remotely) and it knows to delegate to the underlying named query in most cases - pure delegation. But it also knows that in one or two particular instances, specific named queries are invoked in a "special" way, usually involving a stored proc or custom SQL and perhaps combined with elements of object model navigation.In JDO 2.0 the "special" query may still be executed as SQL through the javax.jdo.Query API, and the result is the same persistent objects that would have been retrieve using the named query without "special" treatment; just make sure that the requisite primary key fields are part of the select. Alternatively, if you wanted just field values and not persistent objects, that's supported through the aggregation and projection capabilities of the Query interface. And if you don't want an Object[] of fields per returned row from your projected query, just set the query result to an instance of your own custom JavaBean and you'll get one of those per returned row instead. Each of these permutations is supported by the named query capability, and each can have its usual implementation subverted through interception by a Query factory.The approach described above works without vendor lock-in but does require some homegrown infrastructure. The alternative is to implement a plug-in for your JDO implementation to achieve the same end - less effort overall but a lock-in to the vendor's plug-in architecture.Alternatively, if all you want to do is substitute SQL for the JDOQL of a named query, you can merely alter the query metadata to be SQL-based.That is how banks approach the issue.
    Thanks for the explanation. That makes sense to me. Aside the technical issues, I still don't buy the "transparent" argument for persistence, regardless of the technology. I'm biased because often I have to deal with different database models, which means often a single object may map to a single table, multiple tables joined, and a view. Optimizing queries often means creating new views, so it's not quite as simple as letting the JDO or Hibernate build the query.
    If it was, then JDO and Hibernate would be enough for everyone.
  10. that makes sense[ Go to top ]

    Peter,
    JDO can map a class to a single table and multiple tables that are joined. The way you described your application, I can definitely appreciate the need for views in order to simplify access to the temporal data. But are these views necessary for optimization as well? I don't know the current situation as to whether JDO implementations can use views, both for read access and update. But you definitely can define a persistent class that is based on multiple tables.
  11. Query Language Tradeoffs?[ Go to top ]

    Can anyone explain the tradeoffs between using the JDOQL v. SQL in a typical JDO implementation?

    I think that tuning SQL is a fundamental part of any developer's work with a relational database. Further, there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database (if you want your application to perform, that is).

    I personally don't see any advantage to learning another query language because SQL works very well--unless there are framework-related advantages to JDOQL. Further, I think it's much easier to write a query in a SQL query tool than to write a query as shown above (which to me is much harder to understand and much more error prone, though I haven't ever used JDO); another advantage of normal SQL, I think.

    Thanks for any explanations or contradictions.

    --Kevin
  12. Query Language Tradeoffs?[ Go to top ]

    One of ways to tune queries is to enable SQL log, trace query plan to view statistics tables to create indexes to eliminate table scans, add hints to query, modify views. This kind of JDOQL, OQL, EJBQL or HQL queries are useless and it is hell for DBA or maintainers in practice.
    It is good on emtpy development databases and this kind of application must droped after database grows. SQL support is more usefull than cool and transparent OOP queries and optimistic attachments. Make JDO/EJB a good tool for RDBMS and it will be usefull too. Drop useless QL and forget transparence dream, this is a very big damage for users to sell JDO/EJB as standard way to access RDBMS.
  13. Query Language Tradeoffs?[ Go to top ]

    One of ways to tune queries is to enable SQL log, trace query plan to view statistics tables to create indexes to eliminate table scans, add hints to query, modify views. This kind of JDOQL, OQL, EJBQL or HQL queries are useless and it is hell for DBA or maintainers in practice.It is good on emtpy development databases and this kind of application must droped after database grows. SQL support is more usefull than cool and transparent OOP queries and optimistic attachments. Make JDO/EJB a good tool for RDBMS and it will be usefull too. Drop useless QL and forget transparence dream, this is a very big damage for users to sell JDO/EJB as standard way to access RDBMS.
    Don't forget that in 3-4 years from now the computers with Terabytes of RAM will be probably the reality. So content of most of the databases can be fully kept in memory.
    http://www.prevayler.org/wiki.jsp?topic=BreakthroughsInMemoryTechnology

    Permormace tunning: MS SQL server is alredy doing self-tuning and managment of indicies. And you have almost no control over it. It's far away from being perfect but it will improve (like garabe collecting in java did).
    There is some probability that other RDBMS system will follow this path and most of database tuining will be done automatically.


    Michal
  14. Query Language Tradeoffs?[ Go to top ]

    Yes, I am going to live in the Mars in the future, but I need to develop applications today.
    One of ways to tune queries is to enable SQL log, trace query plan to view statistics tables to create indexes to eliminate table scans, add hints to query, modify views. This kind of JDOQL, OQL, EJBQL or HQL queries are useless and it is hell for DBA or maintainers in practice.It is good on emtpy development databases and this kind of application must droped after database grows. SQL support is more usefull than cool and transparent OOP queries and optimistic attachments. Make JDO/EJB a good tool for RDBMS and it will be usefull too. Drop useless QL and forget transparence dream, this is a very big damage for users to sell JDO/EJB as standard way to access RDBMS.
    Don't forget that in 3-4 years from now the computers with Terabytes of RAM will be probably the reality. So content of most of the databases can be fully kept in memory.http://www.prevayler.org/wiki.jsp?topic=BreakthroughsInMemoryTechnologyPermormace tunning: MS SQL server is alredy doing self-tuning and managment of indicies. And you have almost no control over it. It's far away from being perfect but it will improve (like garabe collecting in java did). There is some probability that other RDBMS system will follow this path and most of database tuining will be done automatically.Michal
  15. Query Language Tradeoffs?[ Go to top ]

    Hi, Michal.

    Self-tuning and index management are a very minor part of optimizing the use of the database. Some databases have been managing indexes mostly on their own for a long time now. Indexes on tables are not any sort of panacea--it's much more complex than that.

    Further, just keeping a database in memory doesn't solve as many problems as one might think--you still have to write to disk (or some persistent store) to commit a transaction, and protect data from concurrent updates, present a consistent picture of the data, etc. This means that placing the database in memory takes much more space than just the current copy of the database. It depends on how many readers and writers exist at any point in time (undo and redo segments, etc).

    Besides, I have to build applications now--I'm not on the 3-4 year plan.

    Thanks,
    --Kevin
  16. Query Language Tradeoffs?[ Go to top ]

    Hi, Michal.Self-tuning and index management are a very minor part of optimizing the use of the database. Some databases have been managing indexes mostly on their own for a long time now. Indexes on tables are not any sort of panacea--it's much more complex than that.Further, just keeping a database in memory doesn't solve as many problems as one might think--you still have to write to disk (or some persistent store) to commit a transaction, and protect data from concurrent updates, present a consistent picture of the data, etc. This means that placing the database in memory takes much more space than just the current copy of the database. It depends on how many readers and writers exist at any point in time (undo and redo segments, etc).Besides, I have to build applications now--I'm not on the 3-4 year plan.Thanks,--Kevin
    I agree will all of your comments. My intention was just say that ejb3 or jdo2 and ORM in generall have a future and this future looks brighter then then reality which we have today.

    Michal
  17. Query Language Tradeoffs?[ Go to top ]

    Oh, I agree. I want to use them, too. I just think it's important that they support native SQL as a "first class" dialect.

    Thanks for your comments, Michal.

    --Kevin
  18. Query Language Tradeoffs?[ Go to top ]

    I'm glad I'm not the only one who shares that opinion. All the [^S]QLs are great at quick development, but fall flat on their face when it comes to complex SQL and tuning. Its similar to the "do everything in configuration" mentality. You look at the code and you have no idea what is happening. And of course, the configuration file is conveniently burried in layers of jar files so that "change is easy" :)
  19. Query Language Tradeoffs?[ Go to top ]

    Then you'll be really impressed that JDOQL supports SQL invocation for the times that it is needed. A better approach, though, is to intercept named query execution as per my "how banks do queries" response. This allows you to keep the SQL, which is brittle to schema changes, out of the application which is mapped to (but insulated from) the schema.

    That way you get the best of both worlds - speed of development and tuning. It also helps people to avoid the pre-optimization anti pattern by getting hung up on queries which have not yet been identified as a source of performance constraint.

    Kind regards, Robin.
  20. Query Language Tradeoffs?[ Go to top ]

    Can anyone explain the tradeoffs between using the JDOQL v. SQL in a typical JDO implementation?
    The advantages of JDOQL are that it is so much simpler than SQL for complex queries, and that it only requires knowledge of the object model, rather than the names of tables and columns in the relational model (good for when you have different people managing each, or when you develop and deploy on different DBs, or switch DBs for performance or other reasons).

    For example, consider a JDOQL filter on the hypothetical Employee class like:
    "!(projects.contains (proj) && proj.manager.firstName == 'Abe')"
    This means "find me all the employees who do *not* have any projects managed by Abe". Now imagine the SQL for that. Hint: you need a subselect and joins between at least 3 tables... possibly more depending on whether Employee is a subclass and what inheritance mapping strategy it uses.

    So JDOQL allows for rapid development. Later, if you discover that your DB is creating a horrible execution plan for this query, then by all means tweak it, either by plugging into the vendor's SQL generation system, or by reverting to a straight SQL query.
  21. Query Language Tradeoffs?[ Go to top ]

    The advantages of JDOQL are that it is so much simpler than SQL for complex queries, and that it only requires knowledge of the object model, rather than the names of tables and columns in the relational model (good for when you have different people managing each, or when you develop and deploy on different DBs, or switch DBs for performance or other reasons).
    Why do we need to use two models ? Do you think it is possible to write something meaningfull without relational model knowlege ?
    If you need "alias" then you can use it in SQL too.
  22. Query Language Tradeoffs?[ Go to top ]

    Yes, you can write meaningful Java code without relational model knowledge. The relational model and Java object model mapping is defined in an XML metadata file. That mapping is the sole place the information resides and is used by the JDO implementation to provide an efficient mapping between your Java object model and the underlying database being accessed. In your JDO application, you only need to interact with your Java object model, there is no need to use the relational model. Get a book about JDO and learn about it. I have the feeling that some of the people throwing darts here at JDO are not that familiar with it. There are a number of books that describe JDO.
  23. Query Language Tradeoffs?[ Go to top ]

    Hi, David.

    So JDO abstracts the database concurrency model and schema characteristics? How does it do this in an efficient manner? The concurrency models of leading databases are vastly different (despite what many people think). How does JDO handle this?

    Further, and perhaps unfortunately, for performance reasons, an object model often has to be adjusted to efficiently map to a relational model. These changes often include navigability and inheritance (and more). How does JDO compensate for (what I would consider) a simple fact of the impedance mismatch between an object and relational model?

    In short, I find it somewhat difficult to believe that someone can build an efficient application without a solid knowledge of the database, including the concurrency model and the schema in use.

    I'm happy to be wrong, though.

    Thanks,
    --Kevin
  24. Query Language Tradeoffs?[ Go to top ]

    How does JDO compensate for (what I would consider) a simple fact of the impedance mismatch between an object and relational model?
    The impedance mismatch between the relational and object models is well know, of course. It's the same problem that every ORM tool faces, whether it be a JDO implementation, Hibernate, EJB 3, Toplink, etc. And, basically, all these tools solve the problem in the same ways:
    1. Dynamically adapt their behavior to the database in use. This includes varying their SQL, their locking policies, etc.
    2. Provide tools to the developer. Tools to create an efficient schema for a given object model, to create an efficient object model for a given schema, or to wire an existing schema and an existing object model together.
    3. As a last-ditch resort, allow the user to access the underlying JDBC layer directly.

    While the details and specific capabilities of each ORM technology differ, the above broad-strokes strategies don't.
  25. Query Language Tradeoffs?[ Go to top ]

    Hi, Abe.

    Thanks for your list.

    In my view, the only reason to use one of these frameworks is to get my objects in and out of the database. Every time I've used one (and this includes Entity Beans), I have to jump through hoops to get the concurrency right (or, at least, acceptable--it's almost never optimal), and they always generate SQL that just sucks.

    Now, if JDO will allow me to do native database locking, and not try to do it on its own (because I don't believe it can do it correctly without either being inefficient, just wrong, or more painful than the native database), then that's cool. I don't want it to "be my database"; I just want it for the brokering.

    Thanks,
    --Kevin
  26. Query Language Tradeoffs?[ Go to top ]

    Yes, JDO implementations use the underlying database for locking, though they do some special things for handling optimistic concurrency control. Yes, I have heard a number of people complain about the kind of SQL generated by entity bean frameworks. I suggest you download an eval of a JDO implementation, give it a test drive, observe the SQL it generates, and see for yourself. Put together a simple object model with a few relationships. You should be able to get things up and running in an afternoon.
  27. Query Language Tradeoffs?[ Go to top ]

    Every time I've used one (and this includes Entity Beans), I have to jump through hoops to get the concurrency right (or, at least, acceptable--it's almost never optimal), and they always generate SQL that just sucks.Now, if JDO will allow me to do native database locking, and not try to do it on its own (because I don't believe it can do it correctly without either being inefficient, just wrong, or more painful than the native database), then that's cool. I don't want it to "be my database"; I just want it for the brokering.Thanks,--Kevin
    Of course, I can't speak for all JDO implementations, but I can address your concerns in relation to Kodo (http://www.solarmetric.com).

    First, I think Kodo produces excellent SQL. This includes not only basics like only updating fields that have actually changed, inserting and deleting individual collection/map elements that have changed rather than deleting and re-inserting the entire contents (unless, due to the number of changes, that is more efficient), utilizing update counts to determine optimistic concurrency violations, and so forth, but also more advanced things like:
    - Dynamically ordering SQL updates to meet all foreign key constraints, including circular constraints, with a minimum of trips to the DB.
    - Dynamically ordering SQL to handle relations made to newly persistent objects with auto-incrementing primary keys, so that the final pk values aren't known until flush, also while minimizing DB trips.
    - Maximizing statement batch sizes if statement batching is enabled.
    - Uniquing query results using distinct keyword and subselects when necessary so that a to-many relational join made in a query doesn't mean you get N repeats of the same object in the results.
    - Translation of JDOQL to efficient SQL.

    As far as locking goes: of course you can control the JDBC isolation level Kodo initializes connections with, for a start. And we have multiple different versioning schemes you can use for optimistic locking policies. And we have runtime locking APIs for controlling how individual objects / queries are locked. And you can even completely take over the locking by implementing our LockManager interface. Or of course you can jump down to the JDBC level and lock rows yourself. Not all of this is covered in the same place since it's a little cross-cutting (optimistic versioning vs. locking vs. JDBC access), but here's a link to our reference guide's section on locking:
    http://www.solarmetric.com/Software/Documentation/latest/docs/ref_guide_locking.html
  28. Query Language Tradeoffs?[ Go to top ]

    First, I think Kodo produces excellent SQL. This includes not only basics like only updating fields that have actually changed, inserting and deleting individual collection/map elements that have changed rather than deleting and re-inserting the entire contents (unless, due to the number of changes, that is more efficient), utilizing update counts to determine optimistic concurrency violations, and so forth, but also more advanced things like:- Dynamically ordering SQL updates to meet all foreign key constraints, including circular constraints, with a minimum of trips to the DB.- Dynamically ordering SQL to handle relations made to newly persistent objects with auto-incrementing primary keys, so that the final pk values aren't known until flush, also while minimizing DB trips.
    ... .

    Does this autopersistence algorythm know about concurently executed transactions ?
    It sounds like looking for a problem ( dealock ).
  29. Query Language Tradeoffs?[ Go to top ]

    JDO speeds up your development process and provides good performance for most of your scenarios. JDO can easily run stored procedures where you need. If it's a not religion, you can balance the facilities of JDO together with the performance in stored procedures.
  30. Query Language Tradeoffs?[ Go to top ]

    Hi, Abe.Thanks for your list.In my view, the only reason to use one of these frameworks is to get my objects in and out of the database. Every time I've used one (and this includes Entity Beans), I have to jump through hoops to get the concurrency right (or, at least, acceptable--it's almost never optimal), and they always generate SQL that just sucks.Now, if JDO will allow me to do native database locking, and not try to do it on its own (because I don't believe it can do it correctly without either being inefficient, just wrong, or more painful than the native database), then that's cool. I don't want it to "be my database"; I just want it for the brokering.Thanks,--Kevin
    Yes, of course JDO delegates locking (and transactions, in general) to the database.
  31. One advantage you get with JDO technology is that the JDO companies have true experts into how to most efficiently map object models into relational databases, people like Abe White. To respond to another post, yes I know SQL, I was promoting its use back in the early 1980s and I have used it on a variety of applications since then. But your average Java developer out there is not a SQL expert. And even if they are, they are often under very tight schedule constraints and spending time thinking about how to optimize their SQL is less important than being sure all the functionality of the application is working by the delivery date. With JDO, the optimal mapping strategies have been codified and made mechanical and automated in the JDO tool. Some of you love SQL and want to use SQL. That is fine, you can use SQL and you will not be able to leverage the benefits from defining an object model. But if you are building Java object models and handling their mapping by yourself, you are working in a very inefficient manner. Your facilities are not going to be as sophisticated as the JDO API and for each new class you want to make persistent, you have a lot more work to do. JDO lets you work with Java object models, JDBC lets you work with relational models through the SQL language. For some applications, SQL is an appropriate technology. But for other applications, ones that require the use of object-oriented facilities like encapsulation, inheritance, and polymorphism, JDO lets you base your application on those object models and automates the mapping of those models to the database. And it does so in a manner that also makes your application completely independent of the underlying database. If you use JDBC, you will quickly lock yourself into the SQL dialect of the database you are using. With JDO, the JDO implementation takes care of handling the various SQL dialects.
  32. We use SQL and have no problems to write it, all of my coworkers are SQL experts. If JDO is for "average Java developer" then is not for us and probably my coworkers are rigth about it. I thought we discuss about technologies for enterprice on the server side.
    One advantage you get with JDO technology is that the JDO companies have true experts into how to most efficiently map object models into relational databases, people like Abe White. To respond to another post, yes I know SQL, I was promoting its use back in the early 1980s and I have used it on a variety of applications since then. But your average Java developer out there is not a SQL expert. And even if they are, they are often under very tight schedule constraints and spending time thinking about how to optimize their SQL is less important than being sure all the functionality of the application is working by the delivery date. With JDO, the optimal mapping strategies have been codified and made mechanical and automated in the JDO tool. Some of you love SQL and want to use SQL. That is fine, you can use SQL and you will not be able to leverage the benefits from defining an object model. But if you are building Java object models and handling their mapping by yourself, you are working in a very inefficient manner. Your facilities are not going to be as sophisticated as the JDO API and for each new class you want to make persistent, you have a lot more work to do. JDO lets you work with Java object models, JDBC lets you work with relational models through the SQL language. For some applications, SQL is an appropriate technology. But for other applications, ones that require the use of object-oriented facilities like encapsulation, inheritance, and polymorphism, JDO lets you base your application on those object models and automates the mapping of those models to the database. And it does so in a manner that also makes your application completely independent of the underlying database. If you use JDBC, you will quickly lock yourself into the SQL dialect of the database you are using. With JDO, the JDO implementation takes care of handling the various SQL dialects.
  33. No one is asking or forcing you to stop doing SQL.

    I assume you are not doing object models. If you don't care about having an object model, then don't use JDO. If you do want to use object models for your persistent information, then JDO is the JCP standard for doing it in Java.

    Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.
  34. No one is asking or forcing you to stop doing SQL.I assume you are not doing object models. If you don't care about having an object model, then don't use JDO. If you do want to use object models for your persistent information, then JDO is the JCP standard for doing it in Java.Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.
    Yes, my objects are more data structures than objects models. I see code and ideas on forums, blogs and I am sure most of "enterprise" applications are implemented this way : Statefull services like session beans, DAO and DTA/value objects.
    This is not "Object Model", as I understand JDO PersistenceManager is a set of "procedures" too. Evrything usel and domain model is RDBMS.
    This discussion helps me understand it, It was very usefull for me and I have no more commens.
  35. You could implement your DAO objects using JDO to do all the mapping work for you automatically. JDO lets you get this part of the task done much faster than coding this yourself. It automates this mapping behavior, and does so in a uniform manner throughout your object model. It also allows you to query relative to that object model. I doubt your handcrafted OR mapping supports queries at the object level. It is extremely rare for an application to undertake that level of sophistication. JDO also automatically tracks your updates, to fields and relationships and then automatically maps these updates back to the database, without a single line of code written by you. JDO is going to be much more productive than you coding this all yourself.

    When I talk about persistent objects, I am not referring to the JDO PersistenceManager, that is not part of your domain model, that is an interface used to access services of the JDO interface. Yes, every object in an object model has a set of methods, a set of "procedures". I don't know what your statement about that is supposed to mean. You don't persist the PersistenceManager in JDO. JDO can persistent instances of the Java classes that you (or others) have defined. Your Java classes can be very thin with simple getters and setters, or they can have a very rich set of semantics and behavior, it is entirely up to you.
  36. I thougth, I am do it wrog and I am tired to find some "OOP way". Now I see I was not wrong, This discussion proved it for me, object model on top of relational model is useless. All JDO/EJB advokates say O/R is very good for objects and domain model, but nobody can explain why it I need this object model on top on relational model, I found nothing wrong in relational model, data structures and procedures aka DAO and DTO. Why do I need to create object model on top of relation model and to hide this object model with procedures and data structures ? RDBMS -> Mapping -> Object Model -> DAO (procedures), Is something better than RDBMS -> DAO (procedures), how this object design can be more productyve and performant ?
    You could implement your DAO objects using JDO to do all the mapping work for you automatically. JDO lets you get this part of the task done much faster than coding this yourself. It automates this mapping behavior, and does so in a uniform manner throughout your object model. It also allows you to query relative to that object model. I doubt your handcrafted OR mapping supports queries at the object level. It is extremely rare for an application to undertake that level of sophistication. JDO also automatically tracks your updates, to fields and relationships and then automatically maps these updates back to the database, without a single line of code written by you. JDO is going to be much more productive than you coding this all yourself.When I talk about persistent objects, I am not referring to the JDO PersistenceManager, that is not part of your domain model, that is an interface used to access services of the JDO interface. Yes, every object in an object model has a set of methods, a set of "procedures". I don't know what your statement about that is supposed to mean. You don't persist the PersistenceManager in JDO. JDO can persistent instances of the Java classes that you (or others) have defined. Your Java classes can be very thin with simple getters and setters, or they can have a very rich set of semantics and behavior, it is entirely up to you.
  37. Hi all !
    This discussion proved it for me, object model on top of relational model is useless. All JDO/EJB advokates say O/R is very good for objects and domain model, but nobody can explain why it I need this object model on top on relational model, I found nothing wrong in relational model, data structures and procedures aka DAO and DTO...
    I guess it's the good old "OO vs. RestOfTheWorld debate"...
    The same arguments against OO :
    - lack of performance
    - lack of productivity, lack of maturity
    - why should I trust you ?
    The same arguments towards OO :
    - it's cleaner, more maintainble, it holds more semantic
    - it will improve, it's the future
    - try it

    OORM just starts the debate over again. RTFM if you're looking for answers, give it a try, and join the league of happy OO developers... or not... it's up to you.
    Sometimes I wonder if we can really convince people that OO thinking is better, since it's a paradigm shift. Anyway, I wonder why people choose Java if they don't intend to adopt object orientation... I really can't see a good reason.

    My reasons for using OO: mental health and fun. Procedural languages and relational models drive me crazy: lack of clear semantics. Too much complexity to handle for me, I'm not that smart. I enjoy object-oriented thinking.

    Chris
  38. RTFM if you're looking for answers, give it a try, and join the league of happy OO developers... or not... it's up to you.Sometimes I wonder if we can really convince people that OO thinking is better, since it's a paradigm shift. Anyway, I wonder why people choose Java if they don't intend to adopt object orientation... I really can't see a good reason.My reasons for using OO: mental health and fun. Procedural languages and relational models drive me crazy: lack of clear semantics. Too much complexity to handle for me, I'm not that smart. I enjoy object-oriented thinking. Chris
    Yes, OOP is very cool and I like it, but I do not know "happy OO developers", see hibernate forums, design patterns on this site. Looks like evrybody use old good
    record type/struct aka "bean" and prcedure/function aka facade or DAO. Ant I see smart people using this "anti OOP", some people use it as workaruond for EJB performance, some use it without EJB, J2EE Blue Prints are about it too, see PetStore.
    Can somebody explain the value of new JDO and future EJB without religions, buzzwords and dreams like OOP, Transparent Persistence, Independance and for "average JAVA deveper".
    Are JDO and EJB are rigth tools retrieve "stuct" from DB ? I think they are not, there are better tools implemet procedures and to persist records without new QL.
  39. On object models[ Go to top ]

    I've been following this thread with interest - thanks to all of those that have contributed.

    Something so far overlooked in immediate coverage of the EJB 3.0 announcement is the removal of Container Managed Relationships (CMR) from the next reincarnation of entity beans. The term "object model", when applied to a persistent domain, covers a spectrum of possible designs. In a broad-brush treatment this spectrum goes from anaemic (state + property setters) through various degrees of behavioural richness (collaboration establishment + dissolution and collaboration/property validation) to behaviourally complete (all domain-relevant logic).

    EJB 3.0's removal of CMR validates the approach taken by JDO - the object model knows how to manage itself and the persistence service merely synchronizes the in-memory object model with the database. The exception that JDO makes is the explicit support of cascade deletion for obvious performance reasons.

    So finally, with EJB 3.0, what might be called the "main stream" of enterprise developers will be forced by technology to move away from the anaemic model towards having some degree of behaviour in their persistent objects.

    How much behaviour is too little? How much is too much?

    The theorists agree that those objects which are business abstractions should hold behaviour appropriate to those abstractions. There is much published empirical work on how to allocate that behaviour across the model.

    Symptomatically, if you have different applications working on the same model and domain-relevant behaviour is being duplicated then it should be in the domain objects themselves. Equally, if you have behaviour in the domain objects used by one application, and this behaviour is counter to the requirements of a new application using the same domain, then you've inadvertently put application-relevant behaviour into the domain object model and this must be corrected.

    JDO lets the designer choose, and always has. But whichever design approach you choose, JDO will faithfully persist the object model you have designed.

    Kind regards, Robin.
  40. No one is asking or forcing you to stop doing SQL.I assume you are not doing object models. If you don't care about having an object model, then don't use JDO. If you do want to use object models for your persistent information, then JDO is the JCP standard for doing it in Java.Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.
    Yes, my objects are more data structures than objects models. I see code and ideas on forums, blogs and I am sure most of "enterprise" applications are implemented this way : Statefull services like session beans, DAO and DTA/value objects.This is not "Object Model", as I understand JDO PersistenceManager is a set of "procedures" too. Evrything usel and domain model is RDBMS. This discussion helps me understand it, It was very usefull for me and I have no more commens.
    That clears up why you don't understand the beauty of ORM.

    And it makes me wonder why you are using Java? Why not C/C++. Especially if speed is concern. Why not .Net? It integrates great with the vendor platform giving performance and superior integration on that platform.
  41. That clears up why you don't understand the beauty of ORM. And it makes me wonder why you are using Java? Why not C/C++. Especially if speed is concern. Why not .Net? It integrates great with the vendor platform giving performance and superior integration on that platform.
    Why do you think I do not use C++ ? I will use .NET too if it will work on UNIX,
    JAVA, OOP is not a religion. If relational model is better for domain model then I use it and I use OOP then it makes sence.
  42. Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.
    One of the reasons for using an OO language in the first place. If it isn't appropriate in enterprise applications then it definitely isn't useful in non-enterprise applications (read: quick-and-dirty apps?).
  43. Query Language Tradeoffs?[ Go to top ]

    Yes, you can write meaningful Java code without relational model knowledge. The relational model and Java object model mapping is defined in an XML metadata file. That mapping is the sole place the information resides and is used by the JDO implementation to provide an efficient mapping between your Java object model and the underlying database being accessed. In your JDO application, you only need to interact with your Java object model, there is no need to use the relational model. Get a book about JDO and learn about it. I have the feeling that some of the people throwing darts here at JDO are not that familiar with it. There are a number of books that describe JDO.
    I do not need books about JDO. Trust me I know specification and I can implement it myself (BTW It was interesting to read and I did it a few times).
    I must be sure it is a good idea, before to use it in the real projects. Relational model is more usefull than Java object, it is the fact,
    I hope you know relational theory and do not need books about relational algebra, RDBMS, SQL, transactions and concurency control. If you not know it and know about data structures like "bean" only then you can not write something more than PetStore.
  44. Why do we need to use two models? Do you think it is possible to write something meaningfull without relational model knowlege?
    Juozas,

    I think you have hit the crux of the matter. JDO consciously decided to work with only one model -- the model of Java objects that can be persisted. The programs interaction with JDO consists of life cycle requests on persistent objects (find, create, delete, pre-fetch fields, detach, attach, etc.) and of controlling transactional boundaries (except when the container controls them.) As a result, the query language is based on the object model and not the database schema. Is it possible to write something meaningful without relational knowledge. Yes, and why not? You don't have to write a relational database server to get your data persisted, why should you have to write a persistence layer to get your data persisted? The history of software is one of constantly implementing another abstraction. There really was a time when Assembly language was considered a toy. Real programmers wrote their code in machine ops. So yes, JDO is a step in the right direction. Furthermore, the vendors have every incentive to write the most performant code possible.

    David Ezzio
  45. Why do we need to use two models? Do you think it is possible to write something meaningfull without relational model knowlege?
    Juozas,I think you have hit the crux of the matter. JDO consciously decided to work with only one model -- the model of Java objects that can be persisted. The programs interaction with JDO consists of life cycle requests on persistent objects (find, create, delete, pre-fetch fields, detach, attach, etc.) and of controlling transactional boundaries (except when the container controls them.) As a result, the query language is based on the object model and not the database schema. Is it possible to write something meaningful without relational knowledge. Yes, and why not? You don't have to write a relational database server to get your data persisted, why should you have to write a persistence layer to get your data persisted? The history of software is one of constantly implementing another abstraction. There really was a time when Assembly language was considered a toy. Real programmers wrote their code in machine ops. So yes, JDO is a step in the right direction. Furthermore, the vendors have every incentive to write the most performant code possible. David Ezzio
    This is the right direction, if you think object model is better than relational in some way. I do not think so. Sorry if it looks like ignorance, but I like innovations and I like JDO too (As you can see, I have spend a lot of time to talk about it, my coworkers just ignore it).
  46. Query Language Tradeoffs?[ Go to top ]

    BTW, how JDO or EJB can help to switch DBs for some reasons ?
    JDO implementations have native features too, does it means we need standard on top of JDO and EJB to swich between JDO implementations for performance or other reasons ?
  47. switching DBs with JDO[ Go to top ]

    JDO lets you switch between DBs. Your JDO applications, both navigational and query access, will be binary compatible across all databases. By simply changing a couple of properties in a property file, you can switch between Oracle, IBM, (pick your favorite relational database), and a variety of other datastores supporting JDO. This is a major reason why Oracle and IBM don't like JDO, it does not provide vendor lockin. The JDO interfaces have been defined to provide binary compatibility and separation from the JDO implementation. You can have a single persistent class and use it simultaneously with several different JDO implementations (each managing their own database connection) and things work just fine. Every vendor supporting a standard is going to have their own features that you can choose to use or not. That is no reason not to adopt a standard. In JDO, using the standard interfaces, you can switch JDO implementations and underlying databases without having to change a single line of Java source.
  48. switching DBs with JDO[ Go to top ]

    Although hesitant to join this discussion I do feel that the theme of dispelling misinformation must be continued.

    OracleAS TopLink provides our customers with database independence. We generate and support the use of standard and native SQL for all of the major relational database vendors. This is public information in our statement of direction on our Oracle Technology Network (OTN) page.

    Not only do we claim this support but we verify this against all the major vendors and releases. Our enterprise customers are not purely Oracle database or Oracle Application Server. In most cases these large customers must maintain a heterogeneous set of databases and application servers.

    Cheers,

    Doug Clarke
    Product Manager, OracleAS TopLink
  49. switching DBs with JDO[ Go to top ]

    Although hesitant to join this discussion I do feel that the theme of dispelling misinformation must be continued.OracleAS TopLink provides our customers with database independence. We generate and support the use of standard and native SQL for all of the major relational database vendors. This is public information in our statement of direction on our Oracle Technology Network (OTN) page.Not only do we claim this support but we verify this against all the major vendors and releases. Our enterprise customers are not purely Oracle database or Oracle Application Server. In most cases these large customers must maintain a heterogeneous set of databases and application servers.Cheers,Doug ClarkeProduct Manager, OracleAS TopLink
    As I understand this database independence is more usefull for vendor to have more customers. SQL is a standard too, but I think it is better to have performant and tested application for one RDBMS implementation than something for all possible "persistent stores". Most "enterprice" applications are not redistributed like text editors and I do not think database or storage independance is usefull for this kind of application. All ways are good to persist data for PetStore type applications, It was proved a lot of times: EJB,.NET, iBatis, I am sure there is no problems to implement PetStore with JDO too.
    I have changed RDBMS for some applications a few times too, but It was no problems. It takes a few days to port JDBC code or to implement some "abstractions", application must work, perform and to be maintained a few years and I prefer to use native features if it helps to solve my problems and it has more value than my few days.
    I need more arguments to use and to trust standards like new EJB and JDO.
  50. Query Language Tradeoffs?[ Go to top ]

    Why not let JDO 2.0 have a text-based declarative query language too (something like HQL) and leave existing Java-based JDOQL as an alternative. There are situations where one is better then onother and vice versa. Actually, the JDO implementation could parse text-based query and invoke methods to construct Java-based query.

    If there would be existing JDO 2.0 implementation now, I would use it rather then Hibernate, but if I have to choose now, the Hibernate would be the choice.

    Mileta
  51. Query Language Tradeoffs?[ Go to top ]

    Can anyone explain the tradeoffs between using the JDOQL v. SQL in a typical JDO implementation?I think that tuning SQL is a fundamental part of any developer's work with a relational database. Further, there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database (if you want your application to perform, that is).I personally don't see any advantage to learning another query language because SQL works very well--unless there are framework-related advantages to JDOQL. Further, I think it's much easier to write a query in a SQL query tool than to write a query as shown above (which to me is much harder to understand and much more error prone, though I haven't ever used JDO); another advantage of normal SQL, I think.Thanks for any explanations or contradictions.--Kevin
    I totally agree with you. It's amazing that some "Java developers" think it's OK to be dimwits and complete morons when it comes to database design and query optimizaton, and relagate this vital responsibility to DBA's.

    A DBA is a database administrator, not a developer. It's really appalling that these so-called developers should be involved in anything that touches a database. No wonder why their applications perform like snails, and they blame Java for being slow rather than their crappy coding.
  52. Query Language Tradeoffs?[ Go to top ]

    Can anyone explain the tradeoffs between using the JDOQL v. SQL in a typical JDO implementation?I think that tuning SQL is a fundamental part of any developer's work with a relational database. Further, there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database (if you want your application to perform, that is).I personally don't see any advantage to learning another query language because SQL works very well--unless there are framework-related advantages to JDOQL. Further, I think it's much easier to write a query in a SQL query tool than to write a query as shown above (which to me is much harder to understand and much more error prone, though I haven't ever used JDO); another advantage of normal SQL, I think.Thanks for any explanations or contradictions.--Kevin
    Let's remember that if you are using JDO, you are freeing your code to be deployed against virtually any datastore. Could be relational, could be OODBMS, whatever. Having SQL in your application code 1) ties you to a SQL database and 2) forces your applicaiton code to have knowledge of the database schema. By using JDOQL, you allow the the application to be easliy targeted to other datastores without changing your application code. To anyone who knows Java, learning JDOQL is trivial - JDOQL virtually IS standard java syntax.
  53. Query Language Tradeoffs?[ Go to top ]

    Hi Kevin
    there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database
    If you are using JDO then a lot of this responsibility is passed on to the implementation. Developers can concentrate implementing functionality. In a large application there will be some generated queries that need to be replaced with hand written SQL or a stored procedure. This work can be done by the best SQL people on the team. On the prior-to-JDO projects I have worked on the "SQL gurus" spent a lot of time fixing slow/broken queries written by the average developers.

    My contention is that using JDO raises the overall quality of the SQL used by the application. The implementation will produce SQL that is at least as good as what the typical developer codes and is always correct (no missing join conditions etc). The SQL gurus can concentrate on making sure that the really important 5% of queries run as fast as possible.

    Cheers
    Davidplay with JDOQWL
  54. Query Language Tradeoffs?[ Go to top ]

    I am sure "average SQL developer" can not write better than average JAVA code too. EJB 1, EJB 2, JDO 1 have promissed it too, now it is absolete and "architects" going to help for "typical developer" with JDO 2 and EJB 3.
    There is only way to write better than "average" code, lern to write it better.
    Hi Kevin
    there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database
    If you are using JDO then a lot of this responsibility is passed on to the implementation. Developers can concentrate implementing functionality. In a large application there will be some generated queries that need to be replaced with hand written SQL or a stored procedure. This work can be done by the best SQL people on the team. On the prior-to-JDO projects I have worked on the "SQL gurus" spent a lot of time fixing slow/broken queries written by the average developers.My contention is that using JDO raises the overall quality of the SQL used by the application. The implementation will produce SQL that is at least as good as what the typical developer codes and is always correct (no missing join conditions etc). The SQL gurus can concentrate on making sure that the really important 5% of queries run as fast as possible.CheersDavidplay with JDOQWL
  55. Query Language Tradeoffs?[ Go to top ]

    People much more knowledgeable than myself on EJB have indicated that there were big changes required between EJB 1.0 and EJB 2.0, and there will be major differences between EJB 2.0 and EJB 3.0. So with each major release, there is a lot of work to do to migrate to the new release.

    That is not going to be the case with the JDO 1.0 to JDO 2.0 migration. Your current code will not become obsolete. You will have 99% compatibility. JDO 2.0 is standardizing the OR mapping syntax, adding a huge number of extensions to the query language, and adding attach/detach functionality. It is my personal view that these new features of JDO 2.0 are the reason that the EJB community has sprung into action to try and directly compete with JDO, they see what is coming in JDO 2.0 and understand their current EJB model is doomed.

    EJB 1.0 and EJB 2.0 may now become obsolete. But an investment in JDO will not become obsolete.
  56. Query Language Tradeoffs?[ Go to top ]

    EJB 1.0 and EJB 2.0 may now become obsolete. But an investment in JDO will not become obsolete.
    This stuff is more populistic than pragmatic, I agrre, JDO probably did no damage,
    but it will do damage too if "Big JAVA players" will promote it. Everything usefull developer needs is on inet for free, just take it and use it. SQL and RDBMS are standards in enterprise and I do not believe JDO or EJB can change it, but Hibernate is a better tool for "typical" or "complex" web applications (I know it from hibernate forum) and try to learn from it. I want, but I do not use Hibernate to implement my procedures and to persist my structs (I have reasons and I talked about it in this forum), Hibernate 3 is going to be more pragmatic and probably I will use it. I am sure JDO will be a usefull framework for me in the future too, but I think it will take a lot of time, I will wait for it, but I continue to code my procedures :)
  57. So with each major [EJB] release, there is a lot of work to do to migrate to the new release... That is not going to be the case with the JDO 1.0 to JDO 2.0 migration.
    Sorry David, but this is just anti-EJB FUD. The EJB3 specification will preserve backwards compatibility for existing 1.x and 2.x users. It will be entirely up to users whether and when to start using the 3.0 API.

    In other places in this discussion, JDO advocates have said that our insistence on backwards compatibility is some sort of anti-competitive plot. Here you try to say that we don't insist upon it and users will suffer. The JDO camp can't have it both ways: in fact we will provide compatibility precisely to avoid the scenario you describe.

    Both EJB 3 and JDO 2 are doing the right thing in this regard. Both are making sure they look after existing users while adding new capability.
  58. Hi Scott

    To take advantage of EJB 3.0's new persistence architecture a client will essentially have to rewrite their existing Entity Bean investments.

    To build a J2EE-compliant implementation, new vendors will have to provide support for superseded persistence architectures.

    These statements are clear and unambiguous. I suggest that you introduce the JSR-220 group to the concept of the "optional feature"; a well specified capability which guarantees portability amongst the subset of compliant implementations which choose to support that feature, but which not every vendor will necessarily choose to implement.

    I'm glad you're following these discussions. By the way, does EJB 3.0 refer to its new persistence capability with the term "transparent persistence" or "POJO persistence"?

    Kind regards, Robin.
  59. Hi Robin,
    To take advantage of EJB 3.0's new persistence architecture a client will essentially have to rewrite their existing Entity Bean investments.
    Why? We aim to provide high interoperability between the 2.x and 3.0 APIs. There may end up being some devil in the detail but it's a goal. And in any case it likely that within the same company, some projects will use the 2.x API and others will use the 3.0 API.
    ...superseded persistence architectures...
    Interesting choice of words. Note that "superceded" does not mean dropped or even deprecated. The 2.x API will continue to be supported and enhanced. With all the buzz about the new 3.0 API, many have missed that some new features will enhance the existing 2.x API *and* the new 3.0 API.
    ...concept of the optional feature...
    A few have been mooted so far. We may end up having some, but they won't affect backwards compatibility.
    Does EJB 3.0 refer to its new persistence capability with the term "transparent persistence" or "POJO persistence"
    We tend to use the term POJO Entity Beans but not for any scientific reason. It was just that we started by looking at how to do a POJO-oriented session bean and then moved on to apply that approach to entities.

    Best
    Scott
  60. Hi Scott

    Indeed, Entity Beans 2.0/2.1 have not been dropped or deprecated. Instead they have been superceded (apologies for the spelling error!). They have been superceded because of endemic design problems which could not be worked around and which put the community base off their use to a large degree.

    So why must a new entrant to your marketplace support and interoperate with them? Presumably a new entrant would be touting for new business with POJO-Entity Beans. I don't see how this would make things difficult for the users of Entity Beans 2.0/2.1? There would still be established vendors providing a migration path in order to preserve (or perhaps poach) customer relationships.

    Thanks for the clarification of your terminology - let us know how it evolves.

    Kind regards, Robin.
  61. So why must a new entrant to your marketplace support and interoperate with [the EJB 2.x API]?
    Various reasons, but the most important is this: the new simplified API will achieve its goals by staying simple. It is designed to make the most common cases really easy. But there are advanced EJB features which people find useful in more specialised situations. For these cases, the people can fall back on the existing 2.x API.

    Best
    Scott

    ps Cannes? Boy, you JDO guys must be loaded. EJB is a no-frills group. ;-)
  62. Cannes JDO meeting[ Go to top ]

    The Cannes meeting is to coincide with some conference taking place there. It turns out a few of the expert group members will be there, so they set up a JDO meeting. Most of those attending were going to the conference anyway, or were living near by. Trust me, many will not be there, including me...
  63. Scott:
    Cannes? Boy, you JDO guys must be loaded. EJB is a no-frills group. ;-)
    David:
    The Cannes meeting is to coincide with some conference taking place there
    Yea, JAOO. I hope everyone else enjoys it. Personally I thought I might give it a skip and get some culture instead - Cannes Film Festival, Monaco Grand Prix, drop in on David (Coulthard), you know the scene.... ;-)
  64. It is designed to make the most common cases really easy. But there are advanced EJB features which people find useful in more specialised situations. For these cases, the people can fall back on the existing 2.x API.
    Interesting. I'll have to think about that for a while.

    By the way, Scott, is anyone addressing JAOO in Cannes on EJB 3.0? If so I may have to ditch my pre-JDO social agenda and come along to the conference after all. Based in the UK I'm one of those who live close enough for Cannes to be little more than a day-trip and I wasn't planning to actually attend JAOO....

    Kind regards, Robin.
  65. By the way, Scott, is anyone addressing JAOO in Cannes on EJB 3.0?
    Sorry, I dunno. But say hello to the film stars for me.

    Scott
  66. To take advantage of EJB 3.0's new persistence architecture a client will essentially have to rewrite their existing Entity Bean investments.
    I think clients using tools such as Weblogic workshop won't have to face
    these issues as they will be abstracted by the tools.
  67. I suggest that you introduce the JSR-220 group to the concept of the "optional feature";
    No need for introduction, we are well aware of the concept and we rejected it since day one. Having optional features weakens a standard. What good is a specification if you need to read the fine prints in a vendor's documentation to know exactly what you are buying?
    By the way, does EJB 3.0 refer to its new persistence capability with the term "transparent persistence" or "POJO persistence"?
    POJO persistence.

    Personally, I think transparent persistence is a myth and that very few users actually care for it. The semantics of their application is tied to the store they are using, and they want to be fully aware of it.

    --
    Cedric
  68. Yes, and it is my understanding that in Hibernate and in this EJB Pojo persistence, that the developer can continue to use database-specific SQL syntax, which is probably the main reason IBM and Oracle are backing it.

    I would not call transparent persistence a myth, it is real, it has been in use in various languages the past 20 years. People that have used it, love it.

    The issue at hand is whether you can capture all the semantics of your information model, relationships and behavior, and completely express them in one language or not. If you cannot, you have to deal with expressing the information model in 2 languages and environments and this creates a lot of costs. For some applications, SQL has the right expressions to be used to fully define the information model. But for many applications, which seem to define a lot of behavior in Java to manage their information models, JDO allows them to use Java classes and syntax for completly specifying their information model.

    JDO applications are not tied to their datastore, they are completely independent of them, which is why IBM and Oracle do not like JDO. This is about vendor lockin and their desire to maintain control and prevent you from being able to switch databases.
  69. ...it is my understanding that in Hibernate and in this EJB Pojo persistence, that the developer can continue to use database-specific SQL syntax, which is probably the main reason IBM and Oracle are backing it.
    It is my understanding that both JDO2 and EJB3 plan to enhance their own (portable) query languages and that both also plan to allow you to escape to database-specific SQL when desired.

    More fundamentally, both entity beans and JDO both avoid lock-in to a specific RDBMS. I recently was on a project where IBM's WebSphere was persisting entity beans to Oracle. And WebSphere would have been happy to persist them to Sybase, Ingres, etc. instead. Your repeated claim that Oracle and IBM have it in for JDO just misses the point entirely. Both JDO and EJB are useful for avoiding database lock-in.
  70. I would not call transparent persistence a myth, it is real, it has been in use in various languages the past 20 years. People that have used it, love it.
    Right, sorry for the mental shortcut. Let me be more specific.

    I was questioning the importance of transparent persistence, not its existence. I don't think there are a lot of users who suddenly need to switch from an RDBMS to LDAP or to an OODB.

    I would even go further and argue that if a language stops being effective at accessing an RDBMS, it's the language that will be changed, not the RDBMS. There is a staggering number of users out there accessing tables that are more than ten years old, and they will probably keep doing so for many years to come.

    All that being said, I do believe there is some value for transparent persistence to an RDBMS, hence the importance of specifying a standard language, EJB QL, that gets translated into SQL targetted to a specific RDBMS.

    Of course, it's equally important to give access to raw SQL, so we are also providing this in EJB3.

    --
    Cedric
  71. Cedric,
    I agree with everything you are saying in this specific posting.

    JDO does provide transparent persistence to an RDBMS. It does have a standard query language, JDOQL, that gets translated into SQL targetted to a specific RDBMS. And JDO 2.0 provides access to the raw SQL as well. So it sounds like JDO 2.0 meets all these needs.

    JDO can also work with all those old relational tables out there. If people want to use JDO to access them, they should have the right.
  72. I don't think there are a lot of users who suddenly need to switch from an RDBMS to LDAP or to an OODB.
    I agree that you won't need to *switch*, but I can certainly see wanting to *mix* things if I had the chance, for example putting permissioning info in an LDAP store. If the inclusion of such a feature doesn't necessarily compromise the design of a persistence framework, why not offer it?

    -geir
  73. No need for introduction, we are well aware of the concept and we rejected it since day one. Having optional features weakens a standard.
    On the contrary: optional features strengthen a standard. In the JDO specification, optional features are as carefully defined as mandatory ones. It is just not felt that it is absolutely necessary to require all implementors to support such features. The alternative to optional features is to drop such features from the specification entirely, i.e. the least common denominator approach.
    What good is a specification if you need to read the fine prints in a vendor's documentation to know exactly what you are buying?
    Vendors have strong incentives to make their support of optional features widely known--I have not seen any JDO vendor hiding such information. Interestingly, information on supported optional features is also available at runtime.
  74. More than two-third of the ODMG standard was optional. No implementation of this standard exists. The same group of people is responsible for the JDO standard, which was again a disaster. Could you please explain again how optional features "strengthen" a standard and where your evidence for that claim is?
  75. Christian: More than two-third of the ODMG standard was optional. No implementation of this standard exists. The same group of people is responsible for the JDO standard, which was again a disaster.

    You seem quite caught up on this OODBMS thing. I personally know lots of companies using JDO successfully with relational databases (you've no doubt heard of Oracle and Sybase) yet I don't personally know of anyone using JDO with an OODBMS. So from my own limited sample, your suggestions seem way out of wack.

    Further, why do you claim that the JDO specification is a disaster? The fact that it has a signficant number of implementations seems to clearly separate it from this ODMG standard that you keep referring to.

    I know you believe (strongly) in Hibernate, which is natural since you spend a good deal of your time contributing to it (you are, with Gavin, one of the developers of Hibernate, correct?) However, believing in the value of Hibernate should not blind you to the value of alternative approaches to solving similar problems.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  76. Interesting. Before I become even more confused, let's take this step by step:
    More than two-third of the ODMG standard was optional. No implementation of this standard exists. The same group of people is responsible for the JDO standard, which was again a disaster.
    I believe that the JDO expert groups (the ones for JSR 12 and JSR 243) also included people who didn't have anything to do with the ODMG standard. In the sense of full disclosure, for JSR 243, this includes me--but then I'm not 'responsible' for the standard, I merely contribute to it to some extent.

    Also, I'd be interested to learn why the JDO standard was disaster.
    Could you please explain again how optional features "strengthen" a standard and where your evidence for that claim is?
    In my mind, optional features are a good mechanism to provide a solid specification of features that are only applicable or of interest to a subset of the potential implementors of a specification. Instead of forcing the features to be implemented as vendor-specific extensions, the syntax and semantics of these features are as thoroughly specified as mandatory ones. The only difference is that vendors can choose whether to implement an optional feature.

    Interestingly enough, most JDO vendors seem to be very supportive of this concept, although it reduces the opportunities to lock clients into their products. Unfortunately, this can't be said of many vendors of other Java/J2EE products.
  77. In my mind, optional features are a good mechanism to provide a solid specification of features that are only applicable or of interest to a subset of the potential implementors of a specification. Instead of forcing the features to be implemented as vendor-specific extensions, the syntax and semantics of these features are as thoroughly specified as mandatory ones. The only difference is that vendors can choose whether to implement an optional feature.
    Since these features are optional, vendors are free to do absolutely what they please: not implement it, implement it fully, implement it partially or implement it with variations. And they can still claim they are compliant with the specification.
     
    Give all this, you are much better off not mentioning these features in the specification altogether and let the market and customers decide.
    Interestingly enough, most JDO vendors seem to be very supportive of this concept
    Right. Maybe there's a lesson to be learned here...

    --
    Cedric
  78. Since these features are optional, vendors are free to do absolutely what they please: not implement it, implement it fully, implement it partially or implement it with variations. And they can still claim they are compliant with the specification.
    My understanding is different: if a vendor decides to implement an optional feature, it must be implemented exactly as specified. A partial implementation or an implementation with variations does not qualify for JDO compatibility.
  79. Since these features are optional, vendors are free to do absolutely what they please: not implement it, implement it fully, implement it partially or implement it with variations. And they can still claim they are compliant with the specification.
    My understanding is different: if a vendor decides to implement an optional feature, it must be implemented exactly as specified. A partial implementation or an implementation with variations does not qualify for JDO compatibility.
    Regardless of our respective understandings of "optional", I'm sure you see that it's easy for a vendor to get away with pretty much anything. If your understanding is correct, I can still implement half an optional feature, rename a few things here and there just so I can escape the clause and still claim I am compliant.

    --
    Cedric
  80. Regardless of our respective understandings of "optional", I'm sure you see that it's easy for a vendor to get away with pretty much anything. If your understanding is correct, I can still implement half an optional feature, rename a few things here and there just so I can escape the clause and still claim I am compliant.
    I'm afraid I don't see that. What you describe would be a vendor extension and, as such, the implementation would in fact be compliant as in your example the optional feature would not be implemented.

    I have some difficulties following the direction your argument is taking, though: I can implement all sorts of things in addition to, say, the EJB spec and still (rightly) claim I have an EJB-compliant container. Or I can cunningly cut corners in my EJB implementation and claim I'm compliant.

    Your example focusses on people trying to cut corners: what's the difference between cutting corners with regards to an optional vs. a mandatory feature?
  81. Regardless of our respective understandings of "optional", I'm sure you see that it's easy for a vendor to get away with pretty much anything. If your understanding is correct, I can still implement half an optional feature, rename a few things here and there just so I can escape the clause and still claim I am compliant.
    I'm afraid I don't see that. What you describe would be a vendor extension and, as such, the implementation would in fact be compliant as in your example the optional feature would not be implemented.I have some difficulties following the direction your argument is taking, though: I can implement all sorts of things in addition to, say, the EJB spec and still (rightly) claim I have an EJB-compliant container. Or I can cunningly cut corners in my EJB implementation and claim I'm compliant.Your example focusses on people trying to cut corners: what's the difference between cutting corners with regards to an optional vs. a mandatory feature?
    Your implementation is compliant as long as it passes the TCK, which only tests required features. So there is absolutely no need to mentionao optional features in the spec.

    --
    Cedric
  82. Your implementation is compliant as long as it passes the TCK, which only tests required features. So there is absolutely no need to mentionao optional features in the spec.
    So far you have not provided a single compelling reason that optional features are a bad thing in themselves--all your concerns were about people trying to abuse them or, in your last post, the way they are treated (or not) in the TCK.

    As information about which optional features are implemented by a vendor at run-time, it should be straightforward to enhance the TCK to include implemented optional features.

    Regards,
    Oliver
  83. This was meant to read:

    As information about which optional features are implemented by a vendor <em>are available</em> at run-time, it should be straightforward to enhance the TCK to include implemented optional features.
  84. Makes sense to me. It's ironic that Hibernate takes so much advantage of pluggable features and standards, and yet wants to lock other vendors out of the EJB standards process. Hibernate supports pluggable transaction models, pluggable data sources, pluggable dialects...in short, pluggable standards within a standard. That leads to some interesting behavior.

    You can build a Hibernate application with correlated subqueries and outer join syntax. Is that application portable? No...the behavior of the database beneath bleeds through. You might argue that Hibernate is not a good standard:

    [blockquote]
    Since these features are optional, vendors are free to do absolutely what they please: not implement it, implement it fully, implement it partially or implement it with variations. And they can still claim they are compliant with the specification.
    [/blockquote]

    The problem with the JDO 1.0 spec is that it was intentionally crippled by the big relational vendors. They did not want an open interface inviting plug-and-play between rdbms and oodbms. Also, OR vendors did not want the threat in the relational space. Therefore, JDO struck a compromise: no relational mapping. Live to fight another day. The JDO 2 spec has none of these problems.

    Optional pluggable query languages are good, no? Surely you see the promise of supporting either or both both criteria queries and SQL in addition to HQL? What about optional caches? Optional identity factories, including user-defined? Hibernate does all of these things, but since it's an implementation, you see it surfaced as configuration. Right now, you're talking about an implementation, but in EJB3, it turns into a specification. I'll be interested to see how Hibernate frames the language around pluggability.

    Remember, at one point, CMP entity beans were optional features of EJB. How do you think that one turned out?
  85.  The problem with the JDO 1.0 spec is that it was intentionally crippled by the big relational vendors.
    Ah, that's a conspiracy theory I hadn't heard yet.
    Optional pluggable query languages are good, no? Surely you see the promise of supporting either or both both criteria queries and SQL in addition to HQL?
    Absolutely, but if you think I didn't notice that you mischievously inserted "optional" in your question, you are mistaken :-)

    EJB3 supports both EJB QL and SQL. And they are both mandatory. If you want to claim you are EJB-compliant, you have to fully support both and pass the TCK, so that customers know exactly what they are buying.

    Make one of them optional, and you're back to square one with a weakened standard.
    Remember, at one point, CMP entity beans were optional features of EJB. How do you think that one turned out?
    Not too bad, but we made them mandatory in the next version because, in case I haven't been clear enough, "optional" doesn't belong in a spec.

    --
    Cedric
  86. ...in case I haven't been clear enough, "optional" doesn't belong in a spec.-- Cedric
    What about JDBC then? Lots of optional features in there, to reflect the different capabilities of the underlying database: transaction isolation levels, result set types, outer join syntax, etc.

    How many people have ever complained and insisted on making each and every JDBC feature required? Funnily enough, that would virtually turn every single database driver out there non-JDBC-compliant in an instant, because none of them supports the entire JDBC feature set (at least as far as I know).

    I do not claim that it is ideal to have lots of optional features; it's just necessary to reflect different capabilities of backend systems. In the case of JDO 2.0, why not define a comprehensive required feature set for JDO/R, leaving some of the features optional for "basic" JDO compliance?

    Juergen
  87. Ironic, isn't it?[ Go to top ]

    Hibernate is being upheld as the poster child of an excellent persistence implementation, and rightfully so. But it got there based on many optional services. Look, for example, at the JTA implementation. It's not there, out of the box...but if you insert it, you've got to conform to the JTA specification to have your stuff work. The behavior of Hibernate changes with the optional transaction semantics. That, in short, is an optional service.

    You might argue that it splinters the Hibernate implementations. "Can I run two databases, and synchronize transactions across them?" And the answer: "It depends." So what? You make the framework easier to use, and easier to extend. You just need to clearly define the pluggable points within the API, and define how the framework works in either context.

    For example, JDO has optional support for the services that would let you plug into and EJB container. Because some vendors don't care about EJB, it doesn't make sense for them to blow a whole bunch of money to support the rightfully optional features to support EJB.

    My question is this: what happens if this persistence model is wrong, or at least not perfect for every application? For example, what if some of the changes have unintended consequences for Hibernate? Would it not make more sense to talk about how pluggable services like persistence might interoperate with the rest of EJB? Then, you would be free to address services in other specifications.

    In short,

    - Standardization of independent services: good. (standardization of Hibernate: good. Standardization of JDO 2: good. JTA, JMS: good.)
    - Standardization on a model to transparently produce, package, and consume services: good.
    - Standardization of a model that defines exactly which services should be bundled: Horrible.
  88. Optional Features in JDO[ Go to top ]

    It's definitely time for some concrete facts in this discussion. To that end I have listed below the optional features from JDO 1.0. The PersistenceManagerFactory has a method supportedOptions():Collection which returns a Collection of Strings. A JDO implementation which claims support for any of the features below must return the corresponding String as part of that collection. For example, if "javax.jdo.option.Optimistic" is in the returned collection then that feature is supported, otherwise it is not. I've put a brief comment in my own words next to each option.

    javax.jdo.option.TransientTransactional instances which are transient may be made transactional; their state changes are subject to rollback.

    javax.jdo.option.NontransactionalRead instances may be read from the datastore outside a transaction.

    javax.jdo.option.NontransactionalWrite instances may be updated in memory outside a transaction (the datastore is unaffected).

    javax.jdo.option.RetainValues the retain values cache management strategy may be used.

    javax.jdo.option.Optimistic the optimistic transaction strategy may be used.

    javax.jdo.option.ApplicationIdentity instances may have application identity (made up on one or more fields of the persistent instance)

    javax.jdo.option.DatastoreIdentity instances may have datastore identity (provided by the datastore and orthogonal to fields of the instance)

    javax.jdo.option.NonDurableIdentity instances may have non-durable identity (no persistent identity).

    javax.jdo.option.ArrayList instances of ArrayList can be persisted.

    javax.jdo.option.HashMap instances of HashMap can be persisted.

    javax.jdo.option.Hashtable instances of Hashtable can be persisted.

    javax.jdo.option.LinkedList instances of LinkedList can be persisted.

    javax.jdo.option.TreeMap instances of TreeMap can be persisted.

    javax.jdo.option.TreeSet instances of TreeSet can be persisted.

    javax.jdo.option.Vector instances of Vector can be persisted.

    javax.jdo.option.Map fields of type Map can be persistent.
    .
    javax.jdo.option.List fields of type List can be persistent.

    javax.jdo.option.Array fields of type Array can be persistent.

    javax.jdo.option.NullCollection JDOQL filter evaluation will treat Collection references that are null as if they refer to valid but empty collections.

    javax.jdo.option.ChangeApplicationIdentity the primary key fields of an instance with application-identity may be changed.

    javax.jdo.option.Set (mandatory) fields of type Set can be persistent.

    javax.jdo.option.HashSet (mandatory) fields of type HashSet can be persistent.

    javax.jdo.query.JDOQL (mandatory) queries may be expressed using JDOQL.

    Support for these options is strong in the community, with most leading vendors implementing all of them except NonDurableIdentity and ChangeApplicationIdentity.

    Notes:
    • Each of the optional features is very well specified. Furthermore I believe the JDO TCK to have specific tests for each of the features, and a "JDO Compliant" implementation must pass the tests corresponding to each optional feature for which support is claimed.
    • The JDO specification requires that Set, HashSet and JDOQL be implemented. An implementation cannot be JDO compliant without implementing these features and returning the corresponding strings as part of the supportedOptions collection.
    • Of the two durable (persistent) identity types, a JDO cimpliant implementation must support either ApplicationIdentity or DatastoreIdentity, and may support both.
    • There are no optional features specific to RDBMS-based operation in JDO 1.0; the same semantics apply over every datastore.
    • As far as J2EE is concerned, the specification mandates that a JDO implementation use JCA/JTS when running in the "managed" environment, and this is not optional.
    JDO 2.0

    The new optional features in JDO 2.0 will probably be something like:

    javax.jdo.query.BinaryCompatibility conformance to the PersistenceCapable "contract" (interface and semantics) such that classes (in their .class form) managed by one implementation can be managed by another implementation without re-compilation or re-enhancement.

    javax.jdo.query.JDOR support for the JDO 2.0 standard object/relational mapping notation

    javax.jdo.query.SQL queries may be expressed using SQL.

    Kind regards, Robin.
  89. Optional Features in EJB 3.0[ Go to top ]

    javax.ejb.option.EntityBean indicates that the implementation supports the deployment of EntityBean components.

    javax.ejb.option.StatefulSessionBean indicates that the implementation supports the deployment of stateful SessionBean components.
  90. Bruce: The problem with the JDO 1.0 spec is that it was intentionally crippled by the big relational vendors.

    Cedric: Ah, that's a conspiracy theory I hadn't heard yet.

    That's not correct. I do remember having a conversation with you quite some time ago, explaining some of the behind-the-scenes maneuvering by one notable RDBMS vendor who was present on the JDO expert group.

    It may serve your current purposes to deride such a thing as a conspiracy theory, but it's hardly a conspiracy when it's one company looking out for their own bottom line by scuttling a standard. A conspiracy would have to involve more than one company .. you know, like two or maybe even three companies. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  91. exorcising options[ Go to top ]

    Cedric: Since these features are optional, vendors are free to do absolutely what they please: not implement it, implement it fully, implement it partially or implement it with variations. And they can still claim they are compliant with the specification.

    Coming from a company that has excelled in the release of partial implementations of specifications (the initial Weblogic support for Servlet filters as one shining example,) I think you are being at least a little harsh.

    Having functionality be optional in a specification is perfectly legitimate for certain types of standard extensions. In lieu of that, Weblogic (as one example) just tacks on proprietary extensions that customers often have not choice but to use, much to the detriment of their applications' portability.

    I believe there is also a legitimate concern with "optional" functionality in aa specification. It should not be used as a crutch to shepherd in various and incompatible pre-existing notions and implementations. Further, optional behavior should be strictly defined, and run time determinable, and (in its absence) deterministic.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  92. Query Language Tradeoffs?[ Go to top ]

    Juozas

    Why are you participating in this debate? You evidently have no faith in the concept of ORM persisting an Object to a Database. Yet this is the approach currently taken by JDO 1.0 and proposed for EJB 3.0.

    This debate concerns those two technologies. You have no interest in either.
  93. Query Language Tradeoffs?[ Go to top ]

    JuozasWhy are you participating in this debate? You evidently have no faith in the concept of ORM persisting an Object to a Database. Yet this is the approach currently taken by JDO 1.0 and proposed for EJB 3.0.This debate concerns those two technologies. You have no interest in either.
    I like ORM, I just can not use it. I asked people to help me sell it for enterprise, but JDO advocates started to talk about average and typical JAVA developers with no SQL knowlege, Do you think somebody can let me to use my faworite innovation for the real projects ?
  94. Query Language Tradeoffs?[ Go to top ]

    Do you think somebody can let me to use my faworite innovation for the real projects?
    Well, I'm maintaining a small list of features which I want to pursue for JDO 2.1. I hope to discuss these with the JDO 2.0 expert group members when we meet in Cannes this month to prepare the draft JDO 2.0 spec.

    If you know of technical shortcomings in JDO which prevent you from using it in your organization then let me know so that I can either show you how they are addressed by JDO 2.0 or consider adding them to JDO 2.1.

    Thanks, Robin.
  95. Query Language Tradeoffs?[ Go to top ]

    <blockquoteWell, I'm maintaining a small list of features which I want to pursue for JDO 2.1. I hope to discuss these with the JDO 2.0 expert group members when we meet in Cannes this month to prepare the draft JDO 2.0 spec. If you know of technical shortcomings in JDO which prevent you from using it in your organization then let me know so that I can either show you how they are addressed by JDO 2.0 or consider adding them to JDO 2.1.Thanks, Robin.Robin,

    One feature I've been begging for couple since JavaOne 2003 is nested transactions/check points. It was on post 1.0 todo list but it liooks like it will not make it into 2.0
    Any chance for having it in v 2.1? I personally would be satisfied with object level nested transactions/checkpoints without corresponding database checkpoints which, in my opinion, is a pretty easy to implement feature

    Thanks

    Alex
  96. Query Language Tradeoffs?[ Go to top ]

    BTW, enterprise is not "typical" it is "mission critical". How can I sell ORM for "mission critical" with obsolete versions and with future visions only ?
  97. Query Language Tradeoffs?[ Go to top ]

    What is obsolete? JDO 1.0? Sorry - not the case. JDO 2.0 merely standardizes some already available features in terms of O/R mapping and Queries. I guess you could say Detachment is the "new" feature, but it's not exactly a fundamentally required concept, and it's already being trialled in production versions prior to standardization.

    JDO 1.0 is far from obsolete, just don't use the makeTransient() method too much (it's been deprecated). Juozas, just what are you getting at?
  98. Query Language Tradeoffs?[ Go to top ]

    Yes, JDO 1.0 is probably more unknown than obsolete in "mission critical" projects ( I am not sure about all, but this is true in my country ). I need O/R for smart people and for the real "persistent store". You sell JDO as some kind of dream for average developers, but I can not sell O/R this way.
    What is obsolete? JDO 1.0? Sorry - not the case. JDO 2.0 merely standardizes some already available features in terms of O/R mapping and Queries. I guess you could say Detachment is the "new" feature, but it's not exactly a fundamentally required concept, and it's already being trialled in production versions prior to standardization.JDO 1.0 is far from obsolete, just don't use the makeTransient() method too much (it's been deprecated). Juozas, just what are you getting at?
  99. Query Language Tradeoffs?[ Go to top ]

    I believe what I said was that the SQL generated by a JDO implementation is going to be better than what an average developer would handcraft. But I am not going to claim that it is impossible for some SQL experts to generate more efficient SQL than a JDO implementation. The point is that the JDO vendors have expertise in producing very efficient SQL code and this knowledge has been incorporated into the SQL they generate to support the access of your Java object models. Smart people out there ARE using JDO, even people that know how to generate SQL code. JDO lets you very quickly get an object model persisted in a database. Just try it out, it should not take more than an afternoon to make a few classes persistent and write some code that accesses them and does some navigation. In my presentations I give on JDO, and I am sure in presentations that Robin Roos gives, people that have been introduced to the technology for the first time and see the simplicity with which you can persist your object models and access your data, they come up to me after the presentation all excited and exclaim about how great JDO is and that they can't wait to use it. Try it out before trying to find excuses not to use it.
  100. Query Language Tradeoffs?[ Go to top ]

    I have experimented with JDO, Hibernate, I have used OJB for "pilot" too, but it does not count, I do not care about PetStores, all tools are good to implement it (I think PHP is the best technology to implement PetStore).
     JDOQL is unreadable for me and I can not tune ( probably I am not so smart as I think )
    I need support for update/delete queries and give me SQL please.
    I will try it, how can I download JDO 2.0 specification and RI ?
    BTW The last time I have tried to download RI, SUN said I am from a bad country, so I have tried closed source 1.0 implentations, binari RI was about flat files.
  101. Query Language Tradeoffs?[ Go to top ]

    You will get delete queries in JDOQL 2.0. Currently in JDOQL 2.0, updates are not supported, and I doubt they will. JDO 2.0 public draft spec hopefully should be released by JavaOne. You will see commercial implementations of it before Sun has the reference implementation completed, which will support relational databases. Oh, and by the way, if JDOQL and the Java navigational and update capabilities of JDO do not support your needs, JDO 2.0 provides a means for you to get a SQL connection. So you can use either SQL, JDOQL, or JDO navigational access.
  102. Simple Question[ Go to top ]

    I want to build a Java Application that uses a relational database. Can anyone tell me the best way to persist my data ?

    many thanks

    Dan

    ps: how long has Java been around for ?
  103. Simple Question[ Go to top ]

    Do you want the data model of your application to be based on manipulation of tables or objects? That is the question. If your answer is tables, use JDBC. If your answer is objects, use JDO. Java got announced and released to the world in 1995. Here we are, 9 years later, still debating whether to use objects in it or not... ;>) (seems like things are moving so slow in that context...)
  104. Not true[ Go to top ]

    Juozas It's not true that in Lithuania nobody i using OEM.
    I know companies who used ORM or even OODBMS :) in 2000 (companies like NoMagic I worked for them). So stop that bulshit :).
    Regarding OOD and "procedural" systems aproaches there is a use for both.
    If you have complex business logic (insurance for example) to have rich domain makes sense (pricing - scary stuff) and then ORM makes sense to map that domain to the database. But if your system performs CRUD on data with no complicated business rules around it then of course rich domain model does not make any sense at all (80% of application in Lithuania). And then vanila SQL and SP is excellent candidate for implementation.

    Even in rich domain model implementations some parts of domain may be "mapped" to RDBMS by using hand written SQL or SP and this mapping is hidden by using "Domain Object Mapper" abstraction.

    Piece,

    Giedrius
  105. Not true[ Go to top ]

    Hi Giedrius,
    Nice to meat you. I can not talk about tehnologies used in concreate enterprises in Lithuania, sorry. I think, you will understan it. I know NoMagic, they produce sofware for US not for Lithuania, do you live in Lithuania at this time ?
    BTW You can find FoxPro in some large companies and most of then do not use JAVA for "mission critical" systems, but It is very good you are patriot, and want protect our technologies :)
  106. Hi everybody,
    I found all the discussion very interesting.

    However, I tried to search the words "UML", "OOA" and "OOD" in this thread page and I couldn't find them.

    That sounds a little strange to me and it seems to mean all the discussion has been focalized on implementation, query optimization, development (possibly made by "average Java developers" ;^, ), performances and so on.

    One point I would to go more in deep is that the choice of a persistence framework (or the need of using one) has to be considered in the big picture of a project aproach, starting from the requirements to the maintenance:
    - Do we need to manage legacy data? Are they reppresented in relational schemas?
    - Do we have constraints for using any specific language, db, platform and so on?
    - Are our company and our customer more data oriented or object oriented ?
    - What kind of development resources and skills will be allocated for the project.
    - What degree of evolution is forecasted for both data and business rules?
    - Is our application data intensive or elaboration intensive? Is it more OLTP or reporting oriented?
    - ...and a lot of other considerations of the same kind.

    Of course, given the big variancy of these parameters, I see a big space for different solutions like JDO, hand-coded SQL and so on... (the only space I can't see is for entity beans ;^( )

    The very important point is, i guess, if after all the previous considerations we are going to set our project to be Object Oriented (OOA-->OOD-->OOP), or Data Domain Oriented (ERD-->RDBMS-->QUERY-->TUNING). In this second case, I realy don't see the reason for using a persistence framework at all: of course it is still possible using Java with JDBC or eventually working inside an application server with all the usable services like multi db distributed transactions, naming, queues and so on. I know a lot of existing environments where this works fine, and all the "old fashions" roles like DBA, analist, data designer and programmer have fun and are in good health.

    However, if our company and our customers have made the cultural step towards the Object Oriented aproach, we cannot deny the big advantages we can get in all the phases of our projects. In this case, I think both JDO and other current frameworks feel the effects of the current crossing period: so, as in the same project we see designers using UML for Objects and ERD for data (sig), in the same time we have standards and tools trying to solve the "Model Impedence" between OO and Relational models when maybe it is too late for doing the best job.

    I believe that, as UML can be considered a super-set of ERD model (that is, it is possible to design relational schemas starting directly from UML), it is possible to have an unique Conceptual Design of an application, covering both Object Workflow and Data Domain, and all the efforts for making new persistence Tools should be focalized on this phase where, working with Objects (that are, in deep, Entity with behaviour), their relationships and navigability it is easier to discover and describe hints (like reverse links, Map and Collection typing constraints, ...) for producing the best persistence results.

    All the framework we discussed in this thread (I am a JDO user), have the problem to operate on code (i.e. Java Classes) instead than on Design (Object Models), and I find this does not make the thing easier.

    Of course, in every day projects, we often need to make Object Models taking care of existing data, so "later mapping" or, sometime, SQL hand-coding are always useful in a certain degree. But the point (and I end apoligizing for my verbosity), is that framework producers (and I hope JDO standardizers in primis) should pay more attention to the help these products could give to the design phases of a prjects to be able to express all their benefits.
  107. Hi Piergiuseppe

    A thoughtful and well written post - thank you. This probably deserves two replies, one for the persistence framework selection guidelines, and another one (later) on the use of UML and state-of-the-art domain-based design techniques.

    On the framework selection side I'll give a JDO-based perspective and leave others to tell you why you should use POJO-Entity Beans or JDBC.
    - Do we need to manage legacy data? Are they reppresented in relational schemas?
    JDO is datastore agnostic. The datastore might be "legacy", e.g. CICS. There are JDO implementations on the market which target "legacy" datastores. If you can get a JDBC driver for your legacy resource then you can use JDO against it. If not, and if there is no JDO implementation natively supporting it, then you must choose a request/response protocol and the decision is no-longer between JDO and POJO-Entity Beans.
    - Do we have constraints for using any specific language, db, platform and so on?
    JDO presumes a Java platform (J2SE or J2EE; I'm not aware of any J2ME implementations of JDO but technically its feasible). If your DB is JDBC-compliant then JDO will support it. If your DB is not JDBC-compliant then check with the community for support, e.g. (Files, XML Documents, Versant/FastObjects/ObjectStore/Orient ODBMS, etc.).
    - Are our company and our customer more data oriented or object oriented ?
    If data oriented then you're probably more comfortable with an object model which is state-heavy (little behaviour) and maps roughly one class to one table.

    If object oriented then you're possibly comfortable having a larger impedence mismatch with an object model where multiple objects live in one table, or single objects span multiple tables, etc. You might have a little more behaviour in your objects.

    Whichever approach you take, JDO will bridge the Object-Relational Impedence Mismatch and persist your data correctly.
    - What kind of development resources and skills will be allocated for the project.
    JDO uses Java. If you're building a Java system then you already have most of the skills you need. The PersistenceManager/Query interfaces are easy to use. JDOQL uses filter clauses based on Java boolean expressions, so the learning curve is small. I teach JDO in 2 days (plus one day extra for OR Mapping), so this really isn't hard.
    - What degree of evolution is forecasted for both data and business rules?
    I doubt this has a huge impact on your choice of persistence technology. It has an impact on your design. You may choose to externalize business rules through a rules engine. You may choose to encapsulate invocation of queries better to facilitate query tuning. But JDO will probably meet your needs with elegance.
    - Is our application data intensive or elaboration intensive? Is it more OLTP or reporting oriented?
    JDO can't do batch updates (in the sense of apply modification X to all objects of class Y which match filter criteria Z), but it does do statement batching in the JDBC sense of the phrase. Batch updates will need to be encapsulated into a class which then invokes the database over it's native protocol, e.g. SQL. The mechanism for doing this is standard and portable in JDO, although the SQL you use will probably tie you to a particular database schema and the dialect of SQL might tie you to a particular database. Use a factory pattern to ensure pluggability for these few statements.

    However JDO does do batch deletion (delete all objects of class Y which match filter criteria Z), and it does it efficiently by delegating the whole request to the server. (Unless you're implementing the DeleteCallback interface, in which case each object must be deleted in the PersistenceManager so that the preDelete() invocation can be given first).
    - ...and a lot of other considerations of the same kind.
    Piergiuseppe writes well, but I've shown above that none of the criteria he suggests leads to a scenario in which POJO-Entity Beans are better than JDO.

    I'll add one more criteria here:
    You want the domain objects you write, along with the application objects which manipulate the domain objects, to work inside or outside an EJB container, e.g. in Servlets, Client-Server, from Spring Framework, etc.
    Of JDO and POJO-Entity Beans, only JDO satisfies this requirement.

    Kind regards, Robin.
  108. Thanks Robin,

    I practically agree with all your points: my considerations were more for the people who (a few also in this thread) discussed the reasons for adopting a persistence framework when they are able to write optimized SQL or even to tune a DB server. I simple mean: there is nothing wrong in using directly JDBC, it works fine expecially if your aproach is data centric or you make some "batch" or reporting; maybe, if you or your resources feel confortable with SQL and do not have long experience with Java, you could find easier to use a framework less independent to the data source but using more SQL syntax.
    Another point to consider is: your project could be multi-language (in big organizations, like banks, it is not rare to see Java middleware, C++ on backoffice and VB on the client side 8^( ,... ): in this case SQL is portable and you could reuse (for example) the same queries when migrate the client from VB to a Java Client.

    But, of course, if Object Modeling has had a big part in your project, I think you really need a framework and, given the efforts, the results and the standardization of JDO, i can't see at the present moment the need to search for another technology.

    Regards, Piero
  109. ..., but JDO advocates started to talk about average and typical JAVA developers with no SQL knowlege, Do you think somebody can let me to use my faworite innovation for the real projects ?
    I know this ... it's awful: Many salespeople of ORM vendors (including TopLink and LiDo) start with telling you "you do not need to know SQL". This is the most idiotic way of selling an ORM. Actually, you (unfortunately) *need* to know SQL quite well to use ORMs today. We are definitely far away from the time where an ORM is like a compiler in the way that it creates *better* SQL/assembler than an application programmer.

    HOWEVER, this does not mean that ORMs are per se worse than using SQL (in Java, JDBC). I'll post my experiences separately.

    Regards
    Harald M. Mueller
    Germany
  110. ORM vs. JDBC[ Go to top ]

    The advantage of JDO (or any ORMapping) over SQL is, in my experience, *not* simpler queries - this is usually the part that is done more or less well by application programmers. Rather, the advantages are

    (a) No need to write the "loading code" (moving over all that columns into java objects; and create the java objects [which is not that easy if you have cyclical graphs!])

    (b) No need to write "saving code"; especially no need to write code for managing dirty flags or the like.

    (c) The possibility to change the performance characteristics easily by declaring what is to be cached; where to use to joins AT A DIFFERENT PLACE than where the actual query is defined. Ideally, this is done declaratively; with possible overrides in the application.

    I have used OR-Mappings for quite some time (>= 3 years) - unfortunately not yet Hibernate. I'va also *written* a *complete* OR mapping tool, because a year ago, only TopLink was somehow adequate for the job; but it had a few bugs, a few features we needed, and mgmt decided it cost to much for 500+ installations. We use TopLink and my OR-mapping tool in projects with 20+ developers and on databases with 5+ million records and with result sets of sizes above 100000 - so all the people claiming that ORMs cannot be used in "productive" systems are wrong (of course you may argue that every system below size 10million...100million...what-have-you is only a toy system. I dont think so, but that's up to you).

    HOWEVER: I admit readily that using OR mappings in real systems is hard-Hard-HARD!!!

    So why do we do it? The advantage (c) above is crucial - we routinely change the load parameters below a running system without even telling the application programmers - so we have again the old distinction between application programmer and "administrator" - only now it's a "orm admin" or rather - and of course - an "orm+db admin", because this is obviously a joint job. This works quite well (we only had to move out some DBAs who told us that "SQL is the only way to go" - but this is the same as the people who told you that "assembler is the only sensible thing to use"; or "SQL will never match the performance of hierarchical databases" - all these guys had to move on).

    But, after doing that now for 3+ years, I am still not sure whether I'll accept in the next project the huge disadvantages of SQL, or the huge disadvantages of an ORM ...

    Regards
    Harald M. Mueller
    Germany
  111. ORM vs. JDBC[ Go to top ]

    Hi Harald

    A good post with interesting content - thank you.

    Can you describe your "home-grown" ORM infrastructure for us briefly? I'd like to get a feel for where it sits in the broad spectrum that is OR Mapping (Hiberenate, JDO, DAO, EJB 2, EJB 3, etc.).

    Thanks again, Robin.
  112. ORM vs. JDBC[ Go to top ]

    Hi HaraldA good post with interesting content - thank you.
    thx.
    Can you describe your "home-grown" ORM infrastructure for us briefly? I'd like to get a feel for where it sits in the broad spectrum that is OR Mapping (Hiberenate, JDO, DAO, EJB 2, EJB 3, etc.).Thanks again, Robin.
    Below is some example code. I hope that gives you some "feeling" for the machinery.

    A few more pieces of information:

    * Internally, the thing uses reflection to talk to the persistable objects.
    * The ORM I wrote is actually an ORM framework, which allows definition of new mappings for associations quite easily (the usual limitation of ORMs to java.util collection classes is a nightmare if you believe in writing intelligent application specific collection libraries - e.g., collections that store timelines; collections that store Locale-dependent information etc.).
    * By default, the ORM uses "shadow objects" for dirty detection; however, if a BO framework has built-in dirty manipulation, one can tell the ORM to look at that information and not at all keep the shadow objects.
    * The integration with EJB is thin/non-existent - the ORM is actually just an "SQL generator". All the transaction handling is done separately by the application programmer.
    * Building a JDOQL frontend wouldn't be too hard (given the many optional operators in JDOQL ;-) ).

    ------------
    Classes to persist:

    class Bill {
      private int id;
      private Date billDate;
      private List /*<Line>*/ lines;
      public Bill(...) { ... }
      public void setBillDate(...) { ... }
      public List getLines() { return lines; }
    }

    class Line {
      private int billId;
      private int lineNo;
      private String product;
      private double price;
      // ...maybe some setters and getters...
    }

    --------------
    Database tables:

    CREATE TABLE OMQATEST_BILL (
      ID INTEGER NOT NULL,
      BILL_DATE TIMESTAMP,
      PRIMARY KEY (ID)
    );

    CREATE TABLE OMQATEST_LINE (
      BILL_ID INTEGER NOT NULL references OMQATEST_BILL(ID),
      LINE_NO INTEGER NOT NULL,
      PRODUCT VARCHAR(40),
      PRICE NUMERIC(10,2),
      PRIMARY KEY (BILL_ID, LINE_NO)
    );

    ==============
    //// ORM - Declarative part (written once with the info above; run once when program boots; I do not support XML files or the like - but it is easy to map the declarations to some "more abstract data structure"):

    Table tabBills = new Table("OMQATEST_BILL");
    Table tabLines = new Table("OMQATEST_LINE");

    Descriptor desBill = new StandardDescriptor(Bill.class, fieldMapper, tabBills, new String[] { "ID" });
    Descriptor desLine = new StandardDescriptor(Line.class, fieldMapper, tabLines, new String[] { "BILL_ID", "LINE_NO" });
      
    new IntAttributeMapping(desBill, "id", "BILL_DATE");
    new DateAttributeMapping(desBill, "billDate", "BILL_DATE");

    new IntAttributeMapping(desLine, "billId", "BILL_ID");
    new IntAttributeMapping(desLine, "lineNo", "LINE_NO");
    new StringAttributeMapping(desLine, "product", "PRODUCT");
    new DoubleAttributeMapping(desLine, "price", "PRICE");

        
    ListMapping lines = new ListMapping(desBill,
    /*javaField=*/ "lines",
    /*createTriggeringLists=*/ true,
    /*fkColumn=*/ new ReferenceKeyColumnGroup(tabLines, "BILL_ID"),
    /*targetDescriptor=*/ desSimpleLine,
    /*mayBeEmpty=*/ true,
    /*hasForeignKey=*/ true);

    ---------------
    //// ORM - "runtime" part

    UnitOfWork uow = new UnitOfWork(dbConnection);

    // query code;
    // the query language is semantically equivalent to EJBQL
    // (explicit bound variables; implicit exists operator; logical-or semantics), but with extensions for inheritance.

    Select sel = new Select(uow);
    sel.setRootResult("bill", desBill); // EJBQL SELECT...
    sel.addNamedNavigation("bill.line", "line"); // EJBQL "IN(...)"
    sel.setWhere(sel.getAttributeNavigation("bill.billDate").lt(new Date())
                 .and(sel.getAttributeNavigation("line.price").gt(100)));

    // control the select statements w.r.t. the association loading (ideas derived from TopLink)
    // "Batch fetching" means that the lines are fetched with a single select.
    // There is also "inner join fetching" (for non-empty associations only), "outer join fetching", and "direct fetching" (with 1+N behavior)
    // This "query declarative code" is usually put into helper classes that are used for tuning the performance.

    RootClassFetchNode cn0 = sel.createRootNode();
    new BatchFetchNode (cn0, "line", /*lazyLoad=*/true);

    List result = sel.executeQuery(cn0);

    // save code
    Bill bi = (Bill) result.get(0);
    bi = (Bill) uow.registerForUpdate(bi, this.desBill);
    bi.setBillDate(new Date());
    bi.getLines().remove(0);
    uow.save();
    dbConnection.commit();

    ---------------
  113. ORM vs. JDBC[ Go to top ]

    Hi Harald

    Wow - I'm impressed that you've written this infrastructure yourself. Thanks for taking the time to post a sample of its usage.

    I'm sure someone on the JDO Expert Group can post how the same mapping would be achieved with the JDO 2.0 mapping standards. In the mean-time I'd like to point out one or two headline differences in the way that JDO manages similar scenarios:

    1. If the shadow objects are turned off does that improve performance? In JDO, the enhanced object track their dirty state. The source code for the domain objects (you refer to these as Business Objects(BO) I think) does not undertake any change tracking - it's part of the enhanced class's capabilities. This means that JDO always knows which instances of any persistent object are dirty without the developer jumping through hoops.

    2. You register objects with a UnitOfWork, similar to the way TopLink works. This puts the onus on the application developer to be sure he registers all the objects he wants to change. Putting it another way, the UnitOfWork instance must be available to any executing method which decides to mutate a persistent object. This tends to propagate persistence infratstucture knowledge throughout the code. Now there are bad ways to do this (pass a context-style parameter to every method) and better ways (ThreadLocal, anyone?), but it remains key. In JDO, since the implementation knows each object that is dirty (and further knows exactly which fields of that object were changed) no such pre-registration is required.

    3. Reflective approaches tend to make lazy loading of relations difficult - not impossible, necessarily, but certainly difficult. JDO solves this by having each persistence-capable instance indirect through its StateManager before traversing an unloaded relation. In this way, the StateManager can magically make the object exist in memory before the traversal occurs. Once again, this is part of the enhanced class' capabilities, and the domain object developer does not have to do anything to get the behaviour. Which approach do you use?

    That's it for now. I must say I think you're very brave!

    Kind regards, Robin.
  114. ORM vs. JDBC[ Go to top ]

    4. Does your framework require domain objects to have a public constructor? It's unclear from your example. JDO requires that a no-arg constructor exist, but (a) it may be private, and (b) the enhancer will add a protected no-arg constructor if your domain classes do not have one.

    5. You have to save() your UnitOfWork before committing the transaction. In JDO you only need the commit; synchronization with the datastore takes place during the commit operation.

    6. Can you show how you would add a new Line to the Bill instead of removing one? I presume your example code automatically deletes the dis-associated line? In JDO you can just add a reference from Bill (or its Line collection) to a transient instance, and that instance becomes persistent on commit through persistence-by-reacability. Once again, this means that a method adding lines to the bill does not need to obtain a reference to the persistence infrastructure in order to do its work.

    Finally,
    * Building a JDOQL frontend wouldn't be too hard (given the many optional operators in JDOQL ;-) ).
    Smiley face acknowledged. But I thought the only optional JDOQL capability was "unbound query variables" ?

    Thanks again, Robin.
  115. JDO vs Hibernate Study[ Go to top ]

    This is where The Middleware Company should come in :)
  116. ORM vs. JDBC[ Go to top ]

    4. Does your framework require domain objects to have a public constructor?
    It requires nothing: Because you can declare a descriptor roughly like this:

    ... = new Descriptor(MyClass.class, ...) {
             public Object newInstance(ResultSet rs, ...) {
               ...create the object from the result set as you like...
             }
           };

    However, this is of course only the "last ressort" (and allows to to completely blow up the ORM by tweaking the ResultSet. As I said: It's an ORM *framework*). The default logic I've implemented is quite nice, I think: The framework takes the specified PK columns from the descriptor, looks up the their JDBC types on the database and tries to find a constructor with parameters matching those types. This "backfires" in a few complicated cases with nearly equivalent constructors - then the fallback above is used.
    The BO framework mentioned has a much more orthogonal structure, where each BO must have a constructor with an OID parameter (the surrogate key class) - a child's play for the default algorithm :-)
    It's unclear from your example.
    ... which was much too simplistic ...
    JDO requires that a no-arg constructor exist
    ... which excludes classes with final variables initialized in the constructor (of course, the byte-code enhancer can "simply" remove the final flag ... I would throw out a tool doing this immediately).
    5. You have to save() your UnitOfWork before committing the transaction. In JDO you only need the commit; synchronization with the datastore takes place during the commit operation.
    This was a deliberate design decision. When we started to use TopLink (in 2000), the integration with J2EE servers was quite bad - mainly, AFAIK, because the JTA interfaces for integrating with the transaction manager where poorly defined and even more poorly implemented. We got "in-house" code from TopLink for integration with Inprise's appserver; and had a consultant write the integration when we switched to WebSphere 2 years ago. We decided that transaction integration with an appserver is difficult, and that we would not do it.

    Moreover, we found another problem: With commit synchronization in a SessionBean, all the exceptions from the database happen "outside" the application code. Now, I recognize that the point when a database throws an exception (e.g. a unique key violation or referential integrity problem) is not defined - it can be when you do the update; or it can be in the commit. So you might have to catch exceptions on the "client" (be it a Swing client far away, or a webserver or a out-of-the-box Webservice frontend to the EJBeans) anyway.
    But with an ORM, the problem gets much worse because of the ORMs own exception classes: You *cannot* allow these exceptions to bubble up to the client, as the client does not even know (and cannot unmarshal) these exception classes. So you need some point where you do "exception translation" - from the ORM exception classes to some application (or JDK) exception class. With commit synchronization, this is impossible (or awkward - you need a wrapping SessionBean with all methods duplicated; which calls the "inner SessionBean" with transaction attribute RequiredNew).

    As I said, our solution is also not clean - the database *might* throw the exceptions only in the commit. However, in practice, all databases I know throw exceptions quite early, and so we can catch them around the explicit save.

    Last, with many JDBC+J2EE developers on our team, the "behavior model" of a "simple SQL generating ORM" with explicit save() was actually easier to explain: "See, here you would write the UPDATEs and CREATEs; now you write save()".
    6. Can you show how you would add a new Line to the Bill instead of removing one?
    Bill bi = (Bill) result.get(0);
    bi = (Bill) uow.registerForUpdate(bi, this.desBill);
    Line li = new Line(...);
    uow.registerForInsert(li, this.desLine); // [1]
    bi.getLines().add(li);
    uow.save();

    I know, I know: Why [1]? Essentially, there are two ways about registering:

    * Some sort of implicit ("rule-based") registering. TopLink has this, but with a somewhat complex semantics - e.g., you must register objects on "the other side" of an association even if they are not at all changed when the association changes. JDO, of course, has it. I never came around to define a clear semantics of this (considering transient fields, pointers to non-persistent classes, pointers to custom association objects which point to persistent classes; different behavior on new, changed, and deleted objects).

    * Explicit registering as above.

    Obviously, implicit registering can be mapped to explicit registering. So I had to implement the latter anyway. When our application programmers use our BO framework, which keeps track of the dirty status anyway, then they do not have to register anything. Code then looks about as follows:

       MyBO bo = MyBOHandler.newMyBO(...); // a factory approach
       bo.setA(...);
       bo.getB().add(bo2);
       MyBOHandler.save(bo);

    All the UnitOfWork, registering etc. is hidden in the Handler. Thus - and maybe this explains some design decisions - the ORM can be somewhat more "raw", because it does not have to play the part of a BO framework also (as, e.g., JDO does with its dirty mechanism - from my point of view; others, of course, see this the other way round: For them, dirty status handling is *part* of an ORM [although I wonder whether people do (mis?)use e.g. JDO's (AFAIK exposed) status getters for other things, like enabling save buttons in a GUI ...]
    I presume your example code automatically deletes the dis-associated line?
    a. Right now, it does not delete the line ;-). This has to do with a company decision to never delete in application code, but only set a deleted flag ("soft delete"). When reading the association, specialized mappings add a condition "AND DELETED=0".

    b. When I do the real ("hard") delete code, there will be a flag on an association that indicates whether the far end should be deleted on an unlink (but I wont do "garbage collection" or "reference counting" for objects reached by m:n relations ...).

    [I must retract my use of "*complete*" in my initial posting. It is "complete for us" - but probably anyone else would immediately need around 25 more features. Examples from my todo list: table-spanning objects; "implicit 1:1-associations" - two objects reside in a single table row; complete support for class inheritance (like James Gosling, I do no longer believe in class inheritance as a standard design concept; hence our BO framework and ORM have been quite restricted to interface "inheritance" or rather implementation)].
    In JDO you can just add a reference from Bill (or its Line collection) to a transient instance, and that instance becomes persistent on commit through persistence-by-reacability.
    Yes - after I read about JDO's definition of reachability, I think I might implement this little gadget ... but as explained above, it's not necesary for us right now.
    Finally,
    * Building a JDOQL frontend wouldn't be too hard (given the many optional operators in JDOQL ;-) ).
    Smiley face acknowledged. But I thought the only optional JDOQL capability was "unbound query variables" ?
    Last time I read the (or rather: some) JDO spec, at least support for casts and instanceof was optional; and also for some String operators; and last, but not least (but this is outside JDOQL) support for any collection except java.util.Set.

    Regards
    Harald
  117. ORM vs. JDBC[ Go to top ]

    Hi Harald
    which excludes classes with final variables initialized in the constructor
    JDO does not merely "remove" the final flag. Instead it is meaningless to ask JDO to persist a class with final variables and without a no-arg constructor which appropriately initializes them. I must admit I haven't tried this.
    With commit synchronization in a SessionBean, all the exceptions from the database happen "outside" the application code.
    Yes, this is a consideration for anyone exploiting CMT.

    JDO 2.0 makes two specific concessions:
    • Under CMT it is legitimate to close() the PersistenceManager (in application code) prior to the commit taking place (in appserver code). A strict interpretation of the JDO 1.0 spec might have rendered this expected usage to be non spec-compliant.
    • There is now a flush() invocation in the PM. It doesn't commit the transaction, but is intended to identify any consistency issues (including optimistic lock violations). You could flush() in your application code, neatly handling any exceptions. Of course the CMT commit() might still fail, but the incidence of this happening after a successful flush() should be small and timing-related. I know that's not a perfect solution but I think it's the best we can do with CMT.
    Last, with many JDBC+J2EE developers on our team, the "behaviour model" of a "simple SQL generating ORM" with explicit save() was actually easier to explain: "See, here you would write the UPDATEs and CREATEs; now you write save()".
    I get your point. However I'm pleased that "saving" is implicit on commit in JDO, and I hope that the flush() capability fills the gap.
    Right now, it does not delete the line ;-). This has to do with a company decision to never delete in application code, but only set a deleted flag ("soft delete"). When reading the association, specialized mappings add a condition "AND DELETED=0".
    Again, a common requirement. JDO does not directly support this. If you want to set a deleted flag on your object then do that through the model - don't use deltePersistent(). However, should we consider a mapping feature which says, at the extent level (class hierarchy level), when a user deletes the instance just mark it as deleted and always append (!deleted) to the semantics of any query of, or reference traversal to, that extent? I think I see another JDO 2.1 feature for my list....
    Examples from my todo list: table-spanning objects; "implicit 1:1-associations" - two objects reside in a single table row; complete support for class inheritance
    You were quite clear that this was "complete for you" and not a commercially viable framework - we're still impressed. For completeness JDO handles the above items with elegance.
    Last time I read the (or rather: some) JDO spec, at least support for casts and instanceof was optional; and also for some String operators; and last, but not least (but this is outside JDOQL) support for any collection except java.util.Set.
    You're right about Set/HashSet being the only mandatory collection interface/class in JDO. We need to keep the spec implementable for small-footprint environments without sacrificing compliance. However you'll struggle to find an implementation which doesn't support "the usual suspects" from java.util. I believe all query operators to be mandatory, bar unbound query variables (which will possibly become mandatory in JDO 2.0). I'll check and report back.

    Kind regards, Robin.
  118. ORM vs. JDBC[ Go to top ]

    Hi HaraldWow - I'm impressed that you've written this infrastructure yourself. Thanks for taking the time to post a sample of its usage.
    Sure - and thanks. The decision to write it home-grown had a few reasons:

    * 2 years of problems with TopLink (technical; and also its German support);

    * the experience that the tech support of a few other ORM (also JDO) tools we wanted to evaluate did not even understand simple problems/concepts like 1+N behavior or lazy loading.

    * We have a huge BO framework in place, which has its own ideas about objects (dirty handling, caching, intelligent associations non-comaptible with java.util, different methods of lazy loading for the associations, standard value classes like Amount etc.). With TopLink, this resulted in a "war" between the two "intelligent models" - we had to implement an adapter BO layer (e.g. because of TopLink's requirement to use a ValueHolder for a lazy-loading association, but not specifying how you can implement the ValueHolderInterface completely yourself).

    * I could do it (quite deep understanding of OO and patterns - admittedly, one needs quite a heavy machinery to write an orthogonal ORM. Double and triple dispatch are no news to me :-) ).
    I'm sure someone on the JDO Expert Group can post how the same mapping would be achieved with the JDO 2.0 mapping standards.
    However, my example is very simple - so it should be possible easily with all ORM approaches and tools out there.
    1. If the shadow objects are turned off does that improve performance? In JDO, the enhanced object track their dirty state. The source code for the domain objects (you refer to these as Business Objects(BO) I think) does not undertake any change tracking - it's part of the enhanced class's capabilities. This means that JDO always knows which instances of any persistent object are dirty without the developer jumping through hoops.
    I did not follow (and I do not like - but this might be a prejudice) the idea of bytecode enhancement. But, in our case, the framework BOs provide some of that functionality anyway - e.g. dirty tracking (the reason to put this into the framework was actually a request that GUIs can show which objects and attributes have changed; this has been implemented long before thinking about the OR problem - but now it comes in handy, and we want to reuse it). So one could argue that we have our own "enhanced" objects (not byte-code enhanced, but framework-enhanced, using a code generator that generates delegates and many other things).
    And yes, "non-shadowing" does improve performance (because cloning of object graphs is time- and memory-consuming; and risky, because the gc-ing of the clones must be handled correctly - in a framework, ORM, or application).
    2. You register objects with a UnitOfWork, similar to the way TopLink works. This puts the onus on the application developer to be sure he registers all the objects he wants to change. Putting it another way, the UnitOfWork instance must be available to any executing method which decides to mutate a persistent object. This tends to propagate persistence infratstucture knowledge throughout the code. Now there are bad ways to do this (pass a context-style parameter to every method) and better ways (ThreadLocal, anyone?), but it remains key. In JDO, since the implementation knows each object that is dirty (and further knows exactly which fields of that object were changed) no such pre-registration is required.
    Again, as above, JDO cannot do magic - it must also somehow have a reference from a changing object (where an assignment is done) to some "registry of changed objects". As we have our framework, we have much of this in place (e.g., changing objects in a client register to a GUI handler which enables the save button). This mechanisms could be easily extended a little to provide the functionality for the registering problem.

    However, in general, you are of course right: If you do not do magic with a framework or with byte-code enhancement, then you leave it to the application programmer to find his/her way to centralized services (like ORM). Parameters, ThreadLocals, mapping from other context variables (e.g. the current UserTransaction of EJB) are all possible, but definitely messy ways. One day, AOP will come to rescue ... but this is again a messy thing in itself ...
    3. Reflective approaches tend to make lazy loading of relations difficult
    Hu? What does Reflection have to do with lazy loading? Lazy Loading requires that an association can remember whether it has been loaded or not [for an alternative interpretation, see after the next quote]; and trigger a loading on some calls. So the problem has to be solved on the level of the association data structures. In one special case, there is no such "data structure" - namely when the association is implemented with a raw pointer. Again, different ways can overcome this: byte-code enhancement to "enlarge" the pointer to a more intelligent thing; or using a proxy object (like TopLink's valueholders). If a framework has proxies anyway - as ours does -, I want to reuse them. Otherwise, I follow the TopLink approach, but with a real ValueHolder interface that can be implemented in any way.

    With more associations different from java.util, lazy loading in itself requires a clearf semantics definition. For example, we have a "ListWithMaster" - i.e. a List which also defines operations setMaster(Object) [must be one of the members of the list or null] and getMaster(). We defined this after we found out that this structure appears quite often in our applications (Here are man real examples: User can select from languages; prefers one. User can login at clients; has one default. Product is supplied by many suppliers; there is one current supplier. Subsidiaries can span many countries; there is one country with the headquarters. Customers have a few addresses; one main/default/living address. etc.etc.) Now, a lazy loading logic for a ListWithMaster defines 3 states:
    * nothing loaded
    * master loaded
    * all loaded
    Integrating this state machine with an ORM is not that easy, if it is possible at all.
    (Also, of course, the mapping of a ListWithMaster requires an additional field
    on the database; you can get nice FK problems here - TopLink has(or maybe had) a nasty bug which makes it impossible to define mappings for such a collection).
    JDO solves this by having each persistence-capable instance indirect through its StateManager before traversing an unloaded relation.
    It is unclear from this whether each instance or the complete association has state "unloaded/loaded". Above, I assumed this is a property of the whole relation - which makes sense in an RDBMS setting, where loading objects one by one yields the infamous 1+N behavior.
    I never thought about the alternative - each object has its "unloaded/loaded" state, because in our framework, we only have "hollow associations" (like TopLink's IndirectList or ValueHolder), but no "hollow objects".
    In this way, the StateManager can magically make the object exist in memory before the traversal occurs. Once again, this is part of the enhanced class' capabilities, and the domain object developer does not have to do anything to get the behaviour.
    Our framework does the same - application developers just access a list (e.g. with .iterator(), .get(int), but also .getMaster()), and the association magically loads the object - or all the objects in the case of a list; and even the objects of all the similar lists in depth-2 graphs (TopLink's batch loading) if you want this (have specified a BatchFetchNode).

    Now, in closing, I must again state that the decision to write "my own ORM" came mainly from the fact that we realized that integration of two "intelligent object systems" (our framework; and an ORM) is very hard. So we decided to "write an ORM which matches our framework".

    [BTW, this might be a good technical argument why EJB2.0 and apparently 3.0 want to keep the CMP definition inside their realm. But I do not know about the "political" things discussed here in length - those might of course be the real reasons ...]

    I do not know any other BO framework except EJB2.0's EBs, which I' afraid of because I do not see how I can teach them to a bunch of good...mediocre programmers; and where I do not see how I can control the SQL fine enough (JBoss implementation from 18 months ago convinced me to back off - "windowed reading" with INs was the only "optimization" to the 1+N behavior; but that might have changed radically, of course).

    So we wrote our own framework; and then realized that this seems to require your own ORM also. We hope that we do not need to write our won appserver ;-)
    I must say I think you're very brave!
    I'm not so sure. What I have seen in ORMs in the last years is definitely not always architectured and designed by good architects; being convinced that I'm quite good at this, it was not that hard to do it at home; with the added benefit that I can leave out each and every feature which is not really needed in our environment (e.g., right now, there is no support for multiple-database-spanning - although we'll need this).
    Kind regards, Robin.
    Also regards.

    Harald
  119. ORM vs. JDBC[ Go to top ]

    Thanks for the further discussion.

    I like your ListWithMaster abstraction - very common but I've not heard it articulated so clearly until now.

    Something which JDO does not cuurrently contain is the event notification framework by which your Swing GUI can become advised of useful state changes. This could include the making dirty of an object (with field-level granularity, perhaps), commit listeners, etc. Such a capability is intended for JDO 2.0 but will probably not make it into the public draft before JavaOne. If we did provide an event notification capability, what sort of events would be useful?

    Kind regards, Robin.
  120. ORM vs. JDBC[ Go to top ]

    Why don't you just copy the Event system from the Hibernate wiki?
  121. ORM vs. JDBC[ Go to top ]

    Rather, the advantages are(a) No need to write the "loading code" (moving over all that columns into java objects; and create the java objects [which is not that easy if you have cyclical graphs!])
    It is not a very big problem to copy row form data sructure A to data sructure B "JDBCUtils.copy(rs,object),JDBCUtils.copy(rs,collection,MyObject.class) ",
    O/R does it better if it has more meta info, but I never load cyclical graphs from DB to memory.
    (b) No need to write "saving code"; especially no need to write code for managing dirty flags or the like.
    This is usefull, if you use "deattached object" design pattern(I do not want to strat a new debate about it), I know then object changed without "flag" property or local cache and I do not need to load object to update it (O/R need object itself to update it, but I need new data only in memory to update it), but with O/R it is more easy.
    (c) The possibility to change the performance characteristics easily by declaring what is to be cached; where to use to joins AT A DIFFERENT PLACE than where the actual query is defined. Ideally, this is done declaratively; with possible overrides in the application.
    I use cached tables in hashMaps too, but I agree, it is ugly, probably it is better to parse query for this optimization, but it is possible to parse SQL too.

    "c)" is a good optimization, "a)" is not so bad too if you need cyclical graphs, but "b)" probably is not.
    Some O/R tools have a lot of features like query by example or query by criteria to generate dynamic queries, dynamic queries can are usefull for reports, but there are a lot of tools to draw reports and 99.99% of my queries are static in practice.
  122. ORM vs. JDBC[ Go to top ]

    P.S. To outsiders reading this thread - please understand that almost everything written here has been written by someone with a direct financial interest in the success of JDO or EJB3 (myself included).
    Then I'm apparently the naive outsider here - I have no financial interest (except as a potential customer for each ORM solution), I am on no committee mentioned here (and actually on none at all), and I'm interested in that it (the persistence mechanism) just WORKS (for us) ;-)
    Rather, the advantages are(a) No need to write the "loading code" (moving over all that columns into java objects; and create the java objects [which is not that easy if you have cyclical graphs!])
    It is not a very big problem to copy row form data sructure A to data sructure B "JDBCUtils.copy(rs,object),JDBCUtils.copy(rs,collection,MyObject.class) ", ...
    Here is a simple class structure:

    -----

    class OrgEntity {
      OID surrogatePK;
      String name;
    }

    class Department {
      OID surrogatePK;
      List /*OrgEntity*/ soldAt;
      String deptId;
    }

    class Product {
      OID surrogatePK;
      String name;
      Department dptmt;
      Amount price;
    }

    class Amount { // in a helper package
      BigDecimal value;
      String currencyIsoCode;
    }

    -----------

    The database is "obvious" (with a relation table for the m:n relationship between Department and OrgEntity). Here is a query to get all products and departments sold at orgEntity ABC:

    SELECT
      PRODUCT.PK, PRODUCT.NAME, PRODUCT.DPTMT_FK,
        PRODUCT.PRICE_VAL, PRODUCT.PRICE_CUR,
      DEPARTMENT.PK, DEPARTMENT.DEPT_ID
    FROM
      PRODUCT
      INNER JOIN DEPARTMENT ON ...
      INNER JOIN DEPARTMENT_ORGENTITY ON ...
      INNER JOIN ORGENTITY ON ...
    WHERE
      ORGENTITY.NAME = 'ABC';

    Now, create the objects. I hate it.

    Later, someone comes and tells you that there are only a few departments which are cached in an object cache anyway, so for higher performance, you should not load them - change the code.

    - I hate it even more.

    An ORM writes that code for me.
    Can JDBCUtils do that?
    (b) No need to write "saving code"; especially no need to write code for managing dirty flags or the like.
    This is usefull, if you use "deattached object" design pattern(I do not want to strat a new debate about it), I know then object changed without "flag" property or local cache and I do not need to load object to update it (O/R need object itself to update it, but I need new data only in memory to update it), but with O/R it is more easy.
    You still dont know which attributes changed - for this, you need more fine-grained dirty flags (if I understand you correctly).

    And in large project settings, where team 1 develops foundation BOs (like the 4 classes shown above) and team 2 reuses this, you cannot rely on team 1 to design the objects to your needs (except if there is a framework in place which provides similar features).
    Some O/R tools have a lot of features like query by example or query by criteria to generate dynamic queries, dynamic queries can are usefull for reports, but there are a lot of tools to draw reports and 99.99% of my queries are static in practice.
    For us, its more like 80% - there are quite a few search GUIs from which we assemble queries according to which fields are filled. Re the additional features you mentioned - we never used any of them: Which might be wrong.

    Regards
    H.M.M&uuml;ller
    Germany
  123. ORM vs. JDBC[ Go to top ]

    Yes, you are right, if you need object model then you need to map it and you need a very good O/R mapping framework.
    JDBC is not a good way to work with object model, some applications need object model some do not. It is very trivial to understand, but it is not trivial to decide you need object model or not.
    I think if you use services like DAO and data transfer objects, then you probably do not need domain model in objects, I am talking about the real model, not "structs" to represent entities.
    If you do not have object model then you do not have any problems (your domain model is relational ), so you can use simple helpers for JDBC or generate this boring code to access database.
    if you need object model then you have problems and I do not think current O/R tools can solve all problems, I think hibernate doe's it good, but it can be better too (SQL). Probably object oriented database can a good solution too, but I am not expert and can not recommend it.
  124. My campaign of FUD[ Go to top ]

    As I admitted in the other thread, I guess I was wrong on detached objects. Apparently the problem with null values in serialized objects was fixed more recently, after I stopped paying attention to JDO. Certainly JDO1 features this problem in the section which deals with serialization; I'm not sure when and how it was resolved in JDO2.

    There are two further reasons I listed for proxy solutions being preferred:

    --QUOTE:
    Proxy-base solutions have some other wonderful advantages, such as the ability to create an association to an object without actually fetching it from the database, and the ability to discover the primary key of an associated object without fetching it.
    --ENDQUOTE

    And those reasons still apply.

    Lastly, JDOQL -is- an abomination, and the JDO spec -is- too complex and misfeatured. But I am 0% interested in getting into a pissing match over this. I've had my say and will say no more. The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.
  125. My campaign of FUD[ Go to top ]

    JDOQL -is- an abomination, and the JDO spec -is- too complex and misfeatured. But I am 0% interested in getting into a pissing match over this. I've had my say and will say no more. The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.
    You are rigth, continue to work on hibernate and we will help as we can too. I believe hibernate can sove problems like queries friendly for tuning, better SQL support and stored procedures, Hibernate team and community can do it better than JDO or EJB politics with standards and specifications, I think they do not let you to make EJB usefull too.
  126. no technical substance[ Go to top ]

    Instead of using emotionally charged and negative words like abomination, complex and misfeatured, you should provide technical justification with examples. Otherwise, there is no substance to back up your claims.

    You can create an association with an object without actually fetching the object from the database in JDO 1.0. The object identity of an object can be used to acquire a reference to an object representing the object in the database, which can then be used to establish the association. All this can be done without fetching the object from the database. The JDO interface gives the programmer the option of whether to validate the identity or not. But even with validation, it does not need to actually fetch the object from the database until the application initiates access of fields.

    Getting the primary key of an associated object would be a trivial extension to JDO, if you considered it important you should have mentioned it during your brief and limited participation in the JDO expert group. The Java representation of that association is a Java reference in JDO, but the underlying JDO implementation also has the foreign key/primary key values of the associated object. If this is a major source of your issues with JDO, well it can very easily be resolved.
  127. responding to my own post...[ Go to top ]

    Actually, in the case of application identity in JDO, you can get the primary key of an associated object without retrieving the object. All you have to do is traverse the reference and access the fields corresponding to the primary key. This can all be done without fetching the object from the database. Its only the case of datastore identity where you cannot directly access the primary key values. But this is how datastore identity was designed, you are not supposed to directly deal with the representation. So for the typical relational approach of having primary keys, JDO 1.0 handles the situation just fine. So, Gavin, you are wrong again in these new criticisms of JDO.
  128. Misconception[ Go to top ]

    Gavin,

    the problem here is that JDO actually HAS a spec. Hibernate doesn't. If you were to write up a spec covering all peculairities of it, it would not be a pretty sight. It would be right up there with the JDO one.

    Don't forget WHY hibernate is successful. Very few people chose between JDO and Hibernate, very few chooses between Hibernate and EJB. Hiberante is the default choice from the merit of, among other things, it being free, newAndCool and doesn't require an ejb container. Since there's no free ejb container (no, jboss does not count. It simply doesn't qualify as anything other than lots of code and stacktraces) hibernate is going to be picked. It used to be the Ofbiz entity engine (for the same reasons).

    Another thing, this POJO bullshit has to end. There's nothing POJO about persistent objects in Hibernate. They're simply not Plain Old Java Objects. They have contracts with the hibernate persisters, their particulars are specified in configuration files, they are even "enhanced" by that cglib abomination of a tool.

    Another thing that goes with the usage base hibernate has is the forgiving attitude. It's free and newAndCool, so people are going to forgive lots of irritating oddities they would never forgive WebSphere for. Write up specs for it and formalize it and people are going to realize what a bastard piece of software it really is in all its newAndCool:ness.

    I predict that hiber..*cough*..EJB3 is going to end up the same route JDO has with noone using it. It's going to be too hard to implement, too hard to get stable and too hard to get any performance out of it, all the while the people who made hibernate the popular choice it is are all tugging at eachother's unmentionables to the next newAndCool persistence toy.

    In closing, I'm not calling Hibernate bad. Really. I like hibernate and use it for three projects right now. I also like EJB very much. The fourth project uses EJB (including cmp entity beans). But these are all small projects where I have a lot of freedom to change decisions that turned out to be bad.
  129. Misconception[ Go to top ]

    Hi Patrick,
    the problem here is that JDO actually HAS a spec. Hibernate doesn't. If you were to write up a spec covering all peculairities of it, it would not be a pretty sight. It would be right up there with the JDO one.

    Don't forget WHY hibernate is successful. Very few people chose between JDO and Hibernate, very few chooses between Hibernate and EJB. Hiberante is the default choice from the merit of, among other things, it being free, newAndCool and doesn't require an ejb container. Since there's no free ejb container (no, jboss does not count. It simply doesn't qualify as anything other than lots of code and stacktraces) hibernate is going to be picked. It used to be the Ofbiz entity engine (for the same reasons).

    Another thing, this POJO bullshit has to end. There's nothing POJO about persistent objects in Hibernate. They're simply not Plain Old Java Objects. They have contracts with the hibernate persisters, their particulars are specified in configuration files, they are even "enhanced" by that cglib abomination of a tool.

    Another thing that goes with the usage base hibernate has is the forgiving attitude. It's free and newAndCool, so people are going to forgive lots of irritating oddities they would never forgive WebSphere for. Write up specs for it and formalize it and people are going to realize what a bastard piece of software it really is in all its newAndCool:ness.

    I predict that hiber..*cough*..EJB3 is going to end up the same route JDO has with noone using it. It's going to be too hard to implement, too hard to get stable and too hard to get any performance out of it, all the while the people who made hibernate the popular choice it is are all tugging at eachother's unmentionables to the next newAndCool persistence toy.

    In closing, I'm not calling Hibernate bad. Really. I like hibernate and use it for three projects right now. I also like EJB very much. The fourth project uses EJB (including cmp entity beans). But these are all small projects where I have a lot of freedom to change decisions that turned out to be bad.
    These are all interesting points, although I disagree on the EJB point:

    - The reason that Hibernate exists (among others) is that there was a big chunk of the market that wasn't fulfilled by entity EJB, plain JDBC and expensive ORM products (remember - JDO wasn't really available back when Gavin got fed up with entity EJB.) In other words, Hibernate exists because there a natural space to fill.

    - Previous to ORMs (including JDO implementations and Hibernate) there was no standard -- either "spec" or de facto -- for ORM. The closest was Toplink, which was both expensive and problem-plagued.

    - I suggest that Entity EJBs would not have been used anywhere near as much if any other simpler solutions had existed.

    - Unlike when EJB 1.0 was release, when Entity EJB 3.0 comes into a mature market, people won't feel that they *have* to use it, because there are other standard solutions available that are more suited to simple ORM tasks.

    - Entity EJB 3.0 will get used for the same application pieces that would have / should have used Entity EJB 2.x if the apps had been built sooner.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  130. My campaign of FUD[ Go to top ]

    Proxy-base solutions have some other wonderful advantages, such as the ability to create an association to an object without actually fetching it from the database, and the ability to discover the primary key of an associated object without fetching it.
    For the record, you can do this in JDO also. No problem.

    I don't want to get into a "pissing match" either; I just want to stop the misinformation.
  131. My campaign of FUD[ Go to top ]

    Proxy-base solutions have some other wonderful advantages, such as the ability to create an association to an object without actually fetching it from the database, and the ability to discover the primary key of an associated object without fetching it.
    For the record, you can do this in JDO also. No problem. I don't want to get into a "pissing match" either; I just want to stop the misinformation.
    I am sure it is possible without proxies too, cglib has a feature to intercept fields too, but nobody uses it in practice, I know authors, they do not use this stuff for many reasons too.
  132. Speak for yourself[ Go to top ]

    The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.
    Please speak for yourself Gavin. I chose JDO over Hibernate for my project's needs and have been very happy with the decision.

    I think what we're seeing right now, is that a lot of the fanbase for JDO and Hibernate has been divided based upon the type of work being done. I imagine that Hibernate has probably won over more of the "report-style" systems out there, while JDO has won out more of the systems that have complex application logic.

    Based on JDO 2.0, I would say that JDO is poised to grab more market share in reporting systems, as it standardizes query capabilities like projection and aggregation, along with features like attachment/detachment. On the other hand, as things stand now, the only way I can see Hibernate winning me over, is if it implements the JDO standard.

    God bless,
    -Toby Reyelts
  133. It is pretty obvious that the persistence problem is not solved today. The problem will not be perfectly solved by EJB 3.0 nor JDO 2.0. There will be areas of convergence in ORM (e.g., identity, metadata), and other areas of divergence (e.g., transparent persistence). It is not clear today whether query languages are converging or diverging.

    My hope is that the J2EE standards being developed continue to enable innovation and competition by allowing for pluggable implementations. If the chosen standard technology is inappropriate for a particular purpose (like CMP entity beans for sophisticated data models), then choosing an alternative technology or implementation to take its place will always be the natural course of action. However, if those options are impeded by the container, the container will find itself in jeopardy of becoming irrelevant (replaced by better technology).

    It seems almost humorous to see the many camps argue, except for the vitriol, like this is a marketing campaign, when the technical solution still seems far from being at hand. It will become more clear that we have reached a good solution, when there is convergence. The fact that there are heated battles between camps is itself strong evidence that convergence is not at hand. Sometimes JCP standards attempt to push the community towards converging on a particular approach. Failures to do so are a burden on the entire community, because they slow down progress on the Java platform itself (in relation to .NET in particular). I would encourage the Hibernate folks and the JDO folks not to fight, but to work both collaboratively and competitively, while not being overwhelmed by egos, to develop the most generally useful technical solution. And understand that we are still a long way from that goal, if we look outside of the individual camp that often colors our perspective, preventing us from recognizing the needs of the larger Java community.
  134. I would encourage the Hibernate folks and the JDO folks not to fight, but to work both collaboratively and competitively, while not being overwhelmed by egos, to develop the most generally useful technical solution. And understand that we are still a long way from that goal, if we look outside of the individual camp that often colors our perspective, preventing us from recognizing the needs of the larger Java community.
    The JDO EG purposely relaxed the binary compatibility requirement (the requirement to implement javax.jdo.spi.PersistenceCapable, usually done via bytecode enhancement) and made it optional primarily so that Hibernate and TopLink could very easily become JDO2-compliant. I think the JDO EG has shown a willingness to work with others to advance the state of the art in transparent object persistence.

    --matthew
  135. I have started using Hibernate for almost an year. Here's what I have to say:

    1. Most people embraced Hibernate for being *free*. But:
    Based on this most of the Hibernate core developers are extremely arrogant in the Hiebrnate forums. If they don't feel they have a good answer, they start being on defensive and the ultimate argument is something like "hey you didn't pay for this, what do you expect here, go and buy JBoss commercial support"...
    And -very- often you are left alone with no other answer than RTFM.
    This is what you have to PAY for Hibernate being 'free'. Basically they treat you like they always do you a favor and you always owe to them because the product is free, you know...

    2. The documenation is misleading on many points. One of them is regarding to lazy initialization on which Gavin is so proud of inside Hibernate and so critical on how JDO implements it. Sorry Gavin but here you're not arrogant but ignorant, too. Believe me, lazy initialization is a pain to use in Hibernate and is not transparent at all, as they claim in the docs.

    3. There is a lot of resistence among the Hibernate developers when it comes to implement some new feature which Gavin thinks is too hard for him to change the framework for. Because he is not bound by any contract with the user he can afford to say something like: We will not implement this feature, it is too much to change in the UserType hierarchy or so...
    Everything comes down to his sole discretion and Hibernate is his own little toy. He is the developer, he is the one who does professional services, customer service, everything, he is the "King". And interacting with users is not one of his strong points.

    4. Gavin has always been critical at JDO's spec. But, there _is_ a spec, there is a standard and a good one. Lacking an abstract spec, that's why Hibernate is so difficult to evolve and so inflexible.
     
    5. JBoss dropped Hibernate for JDO. While at the begginig of their 'marriage' Hibernate was presented as a future CMP persistence framework, JBoss switched lanes adopting JDO.

    Conclusion:

    I will soon replace all my Hibernate code with a JDO implementation. At least I am not locked in with Gavin. What if he decides tomorrow to retire from Hibernate? The project will go down the drain, most likely ...
  136. Most people embraced Hibernate for being *free*. But:Based on this most of the Hibernate core developers are extremely arrogant in the Hiebrnate forums. If they don't feel they have a good answer, they start being on defensive and the ultimate argument is something like "hey you didn't pay for this, what do you expect here, go and buy JBoss commercial support"...And -very- often you are left alone with no other answer than RTFM.
    http://www.hibernate.org/160.html
    RTFM is not Hibernate specific. Nobody deserve to ask for *free* help before trying to help himself (reading the doc is the first stuff to do) : doing that is the minimum to be respectful (too many times you can read: "Urgent, I don't have to read the doc, please do my job!")
    The documenation is misleading on many points. One of them is regarding to lazy initialization on which Gavin is so proud of inside Hibernate and so critical on how JDO implements it. Sorry Gavin but here you're not arrogant but ignorant, too. Believe me, lazy initialization is a pain to use in Hibernate and is not transparent at all, as they claim in the docs.
    Did you find some leak? Please contribute and add that in the wiki area. Lot's of people already contribute in giving some extra infos on lazy initialization.
    There is a lot of resistence among the Hibernate developers when it comes to implement some new feature which Gavin thinks is too hard for him to change the framework for.
    Did you ask IBM/BEA to change the classloading strategy for your own needs? If we believe the feature will complexify too much the core compared to the gains, we reject it, I don't see anything wrong here. Of course you're free to grap the sources and do you changes
    that's why Hibernate is so difficult to evolve and so inflexible.
    eh ?! Please read the Hibernate3 roadmap and check what have been done in CVS so far.
    ...
  137. <blockquoteJDOQL -is- an abomination, and the JDO spec -is- too complex and misfeatured. But I am 0% interested in getting into a pissing match over this.Just evidence that JDOQL is an abomination. Personally I like using it.
  138. My campaign of FUD[ Go to top ]

    But I am 0% interested in getting into a pissing match over this. I've had my say and will say no more. The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.Gavin, it was you who started the "pissing match" with that misinformed blog entry of yours. And when Abe, David, and Robin have come up with valid technical arguments - you are simply running away from the discussion. I would only assume that you don't have anything technical to counter their arguments with.

    And your statement:
    The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect
    reflects extreme arrogance. If only technical issues could all be decided by popularity contests!

    Regards,
    Kalyan
  139. Lastly, JDOQL -is- an abomination, and the JDO spec -is- too complex and misfeatured. But I am 0% interested in getting into a pissing match over this. I've had my say and will say no more.
    Let me get this straight:

    -- 1. Gavin King pisses on JDO with emotional rhetoric.

    -- 2. Abe White defends JDO with technical arguments, tries to start rational debate.

    -- 3. Gavin King says he doesn't want to start a pissing match and will say no more.

    Sounds like the grade school kid who talks trash until someone challenges him to back it up and then he runs away still muttering trash.

    I'm very glad Gavin King is not representing the JDO community or any JDO vendor. I would be embarrassed by his egotism and arrogance.

    Just from this dicssusion, I can see a difference between Gavin's style and the JDO representative's styles. For example, Gavin's attitude seems to be "Hibernate is the best. All others are worthless. Any ideas that I don't find valuable will not be incorporated into Hibernate. I will not back up my statements with fact."

    Abe White, David Jordan, and Robin Roos seem to have the attitude "JDO is very good. If it does not meet your needs, please let us know so we can look at incorporating your ideas into the spec. If you have any questions or challenges, we will be happy to provide you with the answer or explain why feature X is not there."

    I'm sure both Abe and Gavin are knowledgeable, especially in their own areas, but who would you rather deal with? And whose products do you think will be better over the long haul? Someone so arrogant that he won't discuss the problems he has with the "competition," or people who are open to discussion and even changing their product/spec for your needs?

    For the record, my company chose Solarmetric Kodo JDO because: 1) We wanted transparent persistence that worked today, has a future, and has competing implementations (ie, has a spec). 2) We think Solarmetric provides the best JDO implementation. 3) Solarmetric has superior support and treats their customers well.

    Obviously, Hibernate fails most of those criteria. Which is not to say that it is useless, just not right for our needs.
     The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.
    No offense, but every project I personally know that has chosen Hibernate chose it because it was free. Of course JDO is not perfect and I hear Hibernate is not either. But I would expect that when a free, open source JDO implementation makes it to production quality, Hibernate will see fewer users. Both systems work but only one locks you into a vendor. And believe me, as more people start to get a feel for Gavin King's personality, they won't want to be locked in to him or his software.
  140. Gavin's attitude seems to be "Hibernate is the best. All others are worthless. Any ideas that I don't find valuable will not be incorporated into Hibernate."
    I am sorry but nothing could be further from the truth.

    From the very first day Gavin joined the EJB3 Experts Group, he's been incredibly open-minded and he has worked hard to take Hibernate's ideas and blend them into an "EJB mindset" while incorporating new features (annotations) and listening with an extreme openness to critiques and remarks from the various members of the group.

    The current specification draft is the reflection of a group effort, not that of a single individual, and that's what makes it so good in my opinion.

    --
    Cedric
  141. I am sorry but nothing could be further from the truth. From the very first day Gavin joined the EJB3 Experts Group, he's been incredibly open-minded and he has worked hard to take Hibernate's ideas and blend them into an "EJB mindset" while incorporating new features (annotations) and listening with an extreme openness to critiques and remarks from the various members of the group.
    That may be the case, but from how he has acted in this discussion and his blog entries, I stand by my observation. I'm not saying he is a bad person, I'm saying he is acting arrogantly and without consideration for others. We would all like to know the technical reasons behind his claims, and we'd be interested in a public discussion about them.

    Is he required to explain his reasoning to us and discuss it? Of course not. But he's becoming a public figure for the EJB3 spec and by acting arrogantly, he's reflecting poorly on Hibernate and EJB3.

    I don't know Gavin King personally. He may be the next Mother Theresa. I may want him to marry my sister! But not if he talks to me like he talks to others in this group.

    That was my point. If anyone from Solarmetric had acted like he has in this discussion, you can bet we would be using another vendor.
    The current specification draft is the reflection of a group effort, not that of a single individual, and that's what makes it so good in my opinion.
    I'm not knocking the EJB3 spec. It may be the best thing since sliced bread. I may even want to switch to EJB3 when it comes out and if it is better than JDO. So I agree, the spec is a reflection of a group effort and that is good. I just wish certain members of your group made the effort to discuss their opinions in a polite fashion.
  142. Come on guys, this is quite over the top. Sure, blame Gavin that the EJB expert group didn't chose JDO. There can't be anything wrong with JDO! He used his evil Fleury mental powers to influence the expert group even before he joined! Burn him!

    Some people here have a very weird obsession with this person.
  143. Sure, blame Gavin that the EJB expert group didn't chose JDO.
    I'm not blaming him for not choosing JDO. (Scott Crawford made a valid point on his website why Toplink/Hibernate-style was chosen.) I'm blaming Gavin for acting arrogantly and reflecting poorly on his team. I'm praising the JDO advocates for generally acting professional and defending JDO with reason.

    I also praised Solarmetric's implementation and how it meets our needs. I have no technical opinion of EJB3 because I have yet to use it.
    There can't be anything wrong with JDO!
    Has anyone said JDO is perfect? Has anyone said JDO should always be used for every persistence need everywhere forever and ever?

    The JDO advocates have simply defended false claims against JDO and answered questions. They've owned up to cases where JDO is not a fitting persistence mechanism.
    He used his evil Fleury mental powers to influence the expert group even before he joined! Burn him! Some people here have a very weird obsession with this person.
    Does the Gavin King plush toy and "I (heart) Gavin King" on my office wall give it away?

    If I have made any other claim than "Gavin King acted arrogantly in this discussion and the JDO advocates have generally not, and that will reflect on their respective products/specs" then please tell me what my claim is that is "over the top."
  144. sorry JDO folks[ Go to top ]

    and especially to the nice and honest David Jordan.

    But still (I should not say this because I am sure I would not like the guy), A talented individual that never can be beaten by bureaucratic committee management.

    "A natural Law"

    Regards
    Rolf Tollerud
  145. Gavin,

    JDO features a 'Hollow' instance state specifically to allow creation and association of references, without having to load the target data. This meets the need which proxies are intended for, without actually needing such a workaround. This solution may also have significant advantages over proxy designs.

    Historically, one of the problems with O/R has been identity and uniqueing; and one of the problems with Proxies has been that the proxy identity can differ from the identity of the actual instance once this is loaded. Whether this applies these days or to Hibernate I'm not sure, but the reliability of object identities can be considered a fundamental solidity issue.

    Having worked with JDO for a while, I can agree that some aspects of the internals may be different from a developer's first line of thought. However, this is more the management internals and is for efficiency & performance. The actual API for development use, is reasonably straightforward and effective.


    Cheers,
    Thomas Whitmore

    SCE Limited
  146. nothing beats good old vanilla jdbc. why do we have to bother will all the ejbql, jdoql crap. just use the good old straightforward jdbc.
  147. nothing beats good old vanilla jdbc. why do we have to bother will all the ejbql, jdoql crap. just use the good old straightforward jdbc.
    I found JDBC with some helpers is a very good way to access RDBMS, It does not mean I lost interest in innovations, but to sell experiment as standard is too much.
  148. q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");
    I don't understand why setFilter(), orderBy(), etc take string arguments?! Why for example does java.lang.Comparable not need string parameters, yet setFilter() does?! Why the need to subvert Java's static typing? Has Java hit its syntactic limit? Are POJOs that difficult to checkpoint? Would a little Groovy do more here? I personally believe that static typing is more important than the EJB 3 expert group seems to. Sigh.

    As for field interception, it's mechanical overkill, and unecessary for object checkpointing.
  149. Hi Brian

    Java has the notion of Employee.class but no notion of Employee.name.field. This makes it difficult to render field-level information in a typesafe way without getting into heaps of code generation with the necessary constant definitions.

    Anyway, with SQL and EJBQL generally working in a similarly un-typed way I don't think it's a competitive issue. Of course, if you externalize your queries as metadata-defined "named queries" you could have a tool run through the definitions and validate them against your object model if you wished.

    If you have better ideas about typing queries then let us know for JDO 2.1/2.2.

    Thanks, Robin.
  150. Java has the notion of Employee.class but no notion of Employee.name.field.
    Well, there's java.reflect.Field. This JRE class must be painful to use if the expert group considers strings easier for users. It seems a syntactic deficiency, being unable to refer to class details in a way that javac can validate. With Java I can already refer to a java.lang.Class like Rectangle.class within an expression. The notation needs to be extended to accomodate a class's members. Ie, Rectangle.class.width, and javac would generate a reference to the appropriate java.reflect.AccesibleObject. Then EJB 3 wouldn't need sloppy strings to capture architectural details. The change I proposed above involves an entirely backward compatible change to the Java Language Specification. Sigh.
    If you have better ideas about typing queries then let us know for JDO 2.1/2.2.
    See above. Cheers.
  151. JDO Filters are queries[ Go to top ]

    I don't understand why setFilter(), orderBy(), etc take string arguments?! Why for example does java.lang.Comparable not need string parameters, yet setFilter() does?!
    The reason is that Comparable actually executes the code in the compare() method each time two objects are compared, while JDO interprets the code in the string and builds a query, rather than executing the code as a filter on every candidate object in the DB, which would be very slow.

    But having said that, is there any reason why JDO couldn't accept code (thus providing compile-time checking) and then interpret the byte-code rather than a string?
  152. JDO Filters are queries[ Go to top ]

    Because JDO has been designed to support query processing in the server and that server could either be a relational database server supporting SQL, a relational database that does not support Java in the server, or it could be an object database with its own query support in the server. There were other technical reasons we went this route, but after a long day on this site, I am too tired to remember right now.
  153. JDO Filters are queries[ Go to top ]

    David,

    I just mean that you could conceivably have:

    <code>
    q.setFilter( new Object() { boolean pass(Employee e) {
    return e.getAge() > 50 && !e.isRetired() && e.getProjects().isEmpty(); }} );
    </code>

    The method would never be executed, just interpreted to build a query in the same way that a JDOQL string is interpreted, but it would provide compile time checking.

    Of course you'd need to be sure that the methods you were calling were getters for persistent fields, so perhaps it isn't so useful...
  154. JDO Filters are queries[ Go to top ]

    Hi Tom
    <code>q.setFilter( new Object() { boolean pass(Employee e) {return e.getAge() > 50 && !e.isRetired() && e.getProjects().isEmpty(); }} );</code>
    I really like this idea. Extra Java parameters to the pass method -> JDOQL parameters. Local variables -> JDOQL variables. The anonymous inner class instance could even be replaced by a reference to a pre-generated parse tree at enhancement time. All the implementation has to do at runtime is turn this into SQL for the target database.
    Of course you'd need to be sure that the methods you were calling were getters for persistent fields
    I don't think that it would be hard for the implementation to check this.

    Cheers
    David
  155. q.setFilter( new Object() { boolean pass(Employee e) {return e.getAge() > 50 && !e.isRetired() && e.getProjects().isEmpty(); }} );
    Hopefully, Wes Biggs is monitoring this thread -- he discussed something exactly along these lines last summer at the JDO2 kick-off meeting. In fact, it was because of this idea that we decided to ensure that the JDOQL syntax continues to match up exactly with the Java language syntax, even when the semantics are slightly different (String.matches() in JDO2 terms does not fully support regular expressions, only general wildcard expressions).

    I wouldn't count on this being in the JDO 2.0 spec, but I wouldn't rule it out from a future release, and I wouldn't be surprised to see this functionality available as third-party code that works in conjunction with JDO2.
    The method would never be executed, just interpreted to build a query in the same way that a JDOQL string is interpreted, but it would provide compile time checking.
    Actually, JDO allows for in-memory execution of queries against candidate collections, so conceivably, an implementation could actually choose to execute that method directly when using a candidate collection approach. Kodo actually allows something along these lines today when in-memory filtering / in-memory query processing is important (see the description of MethodQL in the Kodo docs [solarmetric.com]).

    -Patrick

    --
    Patrick Linskey
    SolarMetric Inc.
    http://solarmetric.com
  156. Query language[ Go to top ]

    Yes, there's even an implementation of a code-based query strategy in XORM right now. I'd like to further standardize it and get it in line with the nice stuff you can do in JDK 1.5 with parameterized classes. I have a writeup on the subject that I will polish up and post when I get the chance.

    Here's how it works currently (copied from the XORM user's guide, http://xorm.org/guide.html), assuming Department is a persistent class:

    public abstract class DeptsWithEmpSalary extends Department {
      public Employee emp; // variable
      public boolean evaluate(float sal) {
        return emps.contains(emp) && emp.getSalary() > sal;
      }
    }

    To execute the query, the following code snippet is used:

    Query q = mgr.newQuery(CodeQuery.LANGUAGE, DeptsWithEmpSalary.class);
    Collection deps = (Collection) q.execute(new Float(30000.));
  157. Query language[ Go to top ]

    Whatever happened to query-by-example? It was very easy to learn and was completely validated by javac.
  158. For Hibrenate to give a community open source to commericalize it, so we pay for it, it's not good for commnutiy.

    PartII:
    The best DAO by far is ibatis v2.
    Here is an example:
    <sqlMap namespace='Content'>

    <cacheModel id="content_cache" type="MEMORY" >
    <flushInterval minutes= "2"/>
    <flushOnExecute statement = 'Content.blogInsert' />
     </cacheModel>

    <select id='selectAll' resultClass='java.util.HashMap'
    cacheModel='content_cache'>
    SELECT
    *
    FROM
    content
    order by
    id desc
    limit 5
     </select>

    then you just say
    List l = sqlMap.querryForList("selectAll");

    It simple, fast and people that don't know Java can tune it.

    KISS
    .V
  159. Hi Vic,

    How does it feel to be all alone and still be sure that you are right?
    Nobody answered your post despite the fact that you are quite right.

    A Kafkaean feeling is it not?

    In the future academic institutions will publish work on "the public Opinion", case studies of popular opinions in The Server Side community 1999-2005.

    I know that you are a project recovery doctor. Care to share with us how many customers you have saved from the sicknesses of the "EJB Craze" and "ORM Mania"?

    Regards
    Rolf Tollerud
  160. When doing a project recoveryor regular, I do not even mention EJB. I just assume J2EE is Tomcat/Resin.

    Now we have Faces, even more complexity.
    Good thing C# is coming up!

    .V
  161. The best DAO by far is ibatis v2.
    Thank you!

    I buy the Ibatis story any time of day. Unfortunately keeping it simple simply doesn't sell. ;-)
  162. Obviously, we have two groups of people here:
    (1) those who write software;
    (2) those who sell software.

    Naturally, they have completely different interests.

    Now, talk about innovation and conflict management...
  163. WTF?[ Go to top ]

    I used to write apps that used heaps of Entity beans with container managed relationships. EB's were complex, but nevertheless HEAVILY promoted as a "best practice" by both Sun and all the app server vendors. So I was feeling pretty good about the nifty apps I'd built on EJB when I went to JavaOne '02. I attended a presentation on JDO.

    I remember a mix of fear and confusion as I left the presentation. It was almost immediately clear to me that the Entity Bean model was all wrong for persistence. I felt cheated, in a way, that I had made such a long investment in EJB and that there seemed to be political machinations that had kept JDO largely from seeing the light of day. I was also worried that it would be really hard to learn JDO. Mainly this worry was based on my experience with the complexity of Entity Beans.

    Anyway, that was 2 years ago and I am stoked that I have not written a single entity bean since then. JDO is so much better, and was very easy to learn. I LOVE the fact that JDO is NOT part of J2EE and that it strives to remain fundamentally simple and developer friendly. A few intrenched vendors have shunned JDO and are trying to spread FUD -- it gives JDO a great Underdog status. Frankly, those that shun JDO today were the folks responsible for the real "abomination": the Entity Bean.
  164. Status[ Go to top ]

    A few intrenched vendors have shunned JDO and are trying to spread FUD -- it gives JDO a great Underdog status.


    Yes. I can see that this is going to be fun indeed!
  165. Where is advantage?[ Go to top ]

    I don't see difference for programmer or for runtime between proposed query syntax and pure SQL. For me thigs like this make sense:
    q.setResult (new DbFields[] {Cls1.FirstNameField, Cls1.SecondNameField});
    q.setFilter(new AndCond[] {new GreatThan(Cls1.AgeField, 50), new Not(retired), new Equal(Cls1.DepartmentField.NameField, 'Marketing'), IsEmpty(Cls1.ProjectsField)});
    q.setOrder(new Order[]{new AscOrder(Cls1.employeeIdField}));

    We already have query handler which is translating this pure object queries to Database queries. For really complex queries (agregations with more than 10 relations) we have stored procedures for every database we support. We achieved high flexibility for all queries except really complex queries (which usually took only 10-15% of all application).
    Advantages:
    - Naming check at compile time - when we remove or rename field we will only compile don't retest everything because all those check are done at compile time)
    - Data type check at compile time - when we do datatype change we again don't have to retest everything
    - Open doors to areas like in-memory databases, OODBMS, future RDBMS with better object support

    Why we aren't using full power of Java when we come to database?
    Am I alone with this opinion?
  166. The databases at my workplace tend to have an extremely long lifetime (longer than any single application) and their data tends to be shared between many apps. The tables tend to be well normalized and most tables are designed to be versioned based on an event sequence number (the event sequence number is a foreign key into an event table which keeps track of the date of the event and who made the change). In the versioned tables, no information is ever deleted and or changed. However, new versions can be added and it is always possible to "go back in time" and see what the state of the system was in the past simply by using the appropriate event sequence number. The current version of an entity in that table is the entity with the maximum event sequence number. (There are a few more concepts, but I'll leave it at that for this example.)

    The basic question is, how well can JDO or Hibernate map to this sort of a database design? And if a nontrivial mapping is available, how well does that mapping perform?
  167. Hi Robert

    From JDO's perspective, write some simple Java classes which exhibit the relationships you describe. JDO will faithfully persist this for you and allow you to query and navigate through the model.

    Now, what you describe comes close to a "temporal" model of data, where persistent objects are never deleted and are not even changed: instead the effectivity interval of each object defines the period of time during which its values were effective.

    At present, to manipulate such a model you must write program logic such that:

    1. "alteration" of an object is achieved by making the current object version no longer effective and creating a new object version, with the new vales, which is effective from now until the next change

    2. "deletion" of an object is achieved by making the current object version effective only until the time at which the delete was committed.

    3. "navigating" through a logical one-to-one but temporal relationship is actually querying (through a time-variant collection interface) a set of related object versions for the particular version that is effective.

    4. "queries" include interval filter criteria such that only the appropriate object version is retrieved.

    This represents a large amount of infrastructure management that must be exposed through your domain model. JDO will faithfully persist your domain model, but the management of temporal data and relationships still puts a heavy load on the domain and application designers.

    Beyond JDO 2.0

    On my small list of items for JDO 2.1 is something I currently call "Transparent Time Variance", although I actually believe this is just one application of something more abstract called "Query Parameterisation".

    In my model, relationships and objects can be marked as "temporal". If you
    1. change temporal objects
    2. delete temporal objects
    3. navigate temporal associations
    4. execute queries over temporal extents
    then the JDO implementation supporting my concept (I plan to propose it as an optional feature of JDO 2.1) will transparently alter the behaviour it invokes on the database to be inline with the semantics of maintaining temporal data. This removes the semantic and syntactic complexity from the realm of the domain and application designers.

    Now that's all futures, but it's a future I find very exciting. It would have huge benefits in the investment banking sector which occupies much of my consulting time. Until then, talk to your JDO vendor about their interim plans for supporting this type of data.

    Kind regards, Robin.
  168. Hibernate rules[ Go to top ]

    Lots of opinions. It shows that this something really important is discussed here.

    I read that most JCP members voted against JDO 2 because EJB 3 would duplicate it. So the future of JDO 2 seems in danger right now.

    In my eyes, Gavin King is THE guru for ORM. Hibernate is really good.

    For 4 years programmers have fighted with Entity Beans. Now comes JDO 1.0 which seems to be better. But its doom will come because you should not separate people who write specifications and people who implement them. Gavin King does both, thats why Hibernate is a better result in my eyes.

    Hibernate will always be better than any JDO version I think.
  169. Hibernate rules[ Go to top ]

    Actually, a majority of the JCP members voted in favor of JDO. The JSR for JDO 2.0 passed. IBM, Oracle, and BEA voted against it. IBM and Oracle do not like JDO because JDO creates the situation where the applications no longer get locked into the database. All 3 of these companies sell EJB implementations and the EJB crowd has hated JDO because it was so much more popular than entity beans, for a whole bunch of reasons.

    Hibernate may be good, and Gavin can be honored for having developed an ORM that people like and that is distributed for free. I am sure there are a number of people using it because it is free.

    JDO has been out for 2 years now, it is not brand new. There are almost 15,000 developers that are registered users at JDOcentral.com.

    The people that have implemented JDO 1.0 are also working on the specification for JDO 2.0. The JDO 2.0 expert group consists of implementers and users. There are over 15 implementations of JDO now. So you have many companies competing for your business. Gavin did not write a JCP standards specification as your suggest. He developed Hibernate and wrote its documentation. Your claims of the reason for JDO's doom are not factual, and in fact if taken as a good basis for success, argues in favor of JDO.

    Hibernate may be good. But there are a number of people that have been posting here, lodging complaints and criticisms against JDO, and it is very clear that they really don't know JDO. This even includes Gavin King, who did participate a little while on the JDO 2.0 expert group, in fact. But his recent criticisms of JDO, published earlier in this thread, make it very clear that he does not understand JDO. I am sure he is a busy man, supporting and enhancing Hibernate, etc. So the fact he does not understand JDO that well does not lower his stature as the developer of Hibernate. But his criticisms of JDO to date have not been correct. And he seems to have some followers in this thread that are following in his footsteps in that regard. There are topnotch ORM people at the JDO vendors too. Gavin is not the only person in the world that understands ORM.

    Gavin seems to be the big hero now because the EJB 3.0 community appears to be adopting his technology. But don't forget the history of EJB. This EJB group has already designed two releases of entity beans that have largely been rejected. I can't count how many developers I have met who have been burned trying to use entity beans. There are numerous books written on the perils of using entity beans. Most people do one project with entity beans and then swear them off. Yet everyone seems willing to jump on the Hibernate bandwagon because of this endorsement by the EJB community? After messing things up twice already, are you willing to blindly accept their third attempt, before it has even been defined?

    I have yet to meet someone who used JDO on a project and then decided never to use it again. Once people use JDO, they love it and don't want to use anything else.

    I have not heard the schedule for EJB 3.0, but it is probably not going to be out for awhile. It also looks like there will be some kind of merger of Hibernate and TopLink technology. So not only is this vaporware, but there is still opportunity for conflict between the forces at Oracle and Jboss over the definition of this EJB persistence interface.

    The JDO 2.0 spec will be out in a couple months, with commercial implementations right behind that.
  170. Hibernate rules?[ Go to top ]

    The JDO 2.0 spec will be out in a couple months <snip>
    Good conservative expectation setting, David. Personally I don't think Hans will have to wait that long....
  171. Hibernate rules[ Go to top ]

    I have not heard the schedule for EJB 3.0, but it is probably not going to be out for awhile [...] The JDO 2.0 spec will be out in a couple months, with commercial implementations right behind that.
    First of all, a few facts:

    - The EJB3 specification has been in development for nine months already, while JDO 2.0 was accepted as a JSR just three weeks ago.

    - There are incompressible delays in the JCP, so you are certainly not going to see a specification go final two months after it's been accepted as a JSR.

    All that being said, I'd like to step back from the debate and understand the reason for all the namecalling and mudslinging. If you are so sure that EJB3 will fail and JDO2 will be a success, why the disrespect and the aggressive tone?

    It's technology, not religion. Drop the fighting words and let's just get back to work, come up with good specifications and let the market decide.

    I am really tired of the aggressivity displayed by certain people on this thread.

    --
    Cedric
  172. Hibernate rules[ Go to top ]

    Work began on JDO 2.0 in August of 2003 and the JDO expert group (including Gavin King for a few months) has been working hard ever since. I understand the JDO JSR was just accepted, but that does not reflect the status of the expert group. I am on it, so is Robin, we know where it stands. What the JDO expert group will release in a couple months (and as Robin indicates, I am being conservative) is the Public Draft Spec. Several vendors plan on supporting it soon afterwards. So now you know the facts about JDO. When will EJB 3.0 public draft be released?

    No one is calling any names or slinging mud. Gavin, and some of his supporters, have been making statements about JDO in this thread that are completely false. The JDO community has felt compelled to point out things which have been stated that are not true about JDO. There is no disrespect or aggressive tone. But people deserve to hear the truth. Gavin's statements about JDO here were wrong, pure and simple. Pointing out his statements abot JDO are wrong and stating the truth about it is not being disrespectful of him. I think the readers of this forum deserve to know the truth, not more JDO FUD.

    And yes, let the market decide. But the EJB vendors like IBM/Oracle/BEA have tried to kill JDO, to try and stop it from being made available. Yes, let the market decide, not these big players trying to preserve their turf. Entity beans have failed twice (1.0 and 2.0). People are happy with JDO 1.0. They will be ecstatic over JDO 2.0.
  173. Hibernate rules[ Go to top ]

    But the EJB vendors like IBM/Oracle/BEA have tried to kill JDO, to try and stop it from being made available.
    I really don't understand this rampant paranoia either. If we follow your reasoning, Hibernate shouldn't even exist since not only is it not J2EE, it is not backed by any big company and it's not even a JSR (JDO satisfies two of these three criteria).

    If a spec or product is good and fills a need, it will succeed, and no big corporation will ever be able to change that.

    --
    Cedric
  174. Hibernate rules[ Go to top ]

    No rampant paranoia here... IBM/Oracle/BEA did vote against JDO 2.0. About the same time, they are now making it known that they are rallying behind Hibernate in EJB 3.0.

    Hibernate and JDO have done quite well the past few years, despite the big dollars spent by the EJB community to get everyone to use entity beans.

    I don't have any issues with Hibernate itself, as I have not looked at it yet. So you have not seen me criticize Hibernate at all. I won't lodge criticisms against something I don't know about. I have yet to hear any criticisms of JDO in this thread that have been valid. JDO is good and fills a need. So does Hibernate. It is entity beans that will die first in all this, and I don't think there are many users that will be crying over that.
  175. Hibernate rules[ Go to top ]

    No rampant paranoia here... IBM/Oracle/BEA did vote against JDO 2.0.
    Precisely: all they did was vote "no" on the JDO2 JSR, and they gave their reasons.

    I call paranoia when people interpret this vote as a conspiracy destined to kill JDO, that's all.

    --
    Cedric
  176. Hibernate rules[ Go to top ]

    Cedric,
    Two of these companies have been involved in other activities the past few years to thwart JDO, this is definitely not their first attempt, not by far. But I won't go into all those past aggressions.
  177. Hibernate rules[ Go to top ]

    conspiracy destined to kill JDO
    No - certainly intended, but not destined.
  178. Hibernate rules[ Go to top ]

    About the same time, they are now making it known that they are rallying behind Hibernate in EJB 3.0.
    I believe it is a mistake for the container to advocate any services. In the future SOA, declarative services should be decoupled from the container. So if I buy a container from BEA and want to use a security service I bought from IBM that follows a different spec, I should be able to do so (obviously there has to be some minimal agreement in interface but underline minimal). Thus EJB 3.0 should be geared toward supporting a persistence interface and not the entire service. I believe this to be true internally but some of the posts here seem to be getting away from that point.
  179. Off topic, SOA[ Go to top ]

    I believe it is a mistake for the container to advocate any services. In the future SOA, declarative services should be decoupled from the container.
    This is truly the case with the Global Grid Forum's OGSA service architecture. A developer can choose from service containers written in Java, C++, Python, or Perl. They interoperate over the wire, and they're easy to federate. For e-science the numeric services are often written in C++ or ForTran and deployed in a C++ gSOAP container. The middleware services are all written in interpreted languages. These two families of services are then rolled out together as a unified system, and neither knows which language the other uses.
  180. Off topic, SOA[ Go to top ]

    BTW, to generate simple data access service you need nothing more than method declaration and query string strig:

    interface Users{

    @Query "SELECT count(*) > 0 FROM USER WHERE user_name=$1, password=$2 "
    boolean authenticate(String userName,String password);

    }

    It is possible to generate code for EJB,JDO,Hibernate,LDAP or OODBMS without importing any API.
    tool can do it at runtime or at builtime, and it is very trivial to implement this service using JDBC (and I do not think SOA needs something more to implement data access ). It can implement it as or local or as remote, use SOAP or RMI and to check permissions.
    Data Access is one of SOA aspects and probably it is not so complex and it is declaratyve. And tool can generate interface or implementation for any programming language. So O/R is just a toy for people who understand SOP and AOP.
  181. Off topic, SOA[ Go to top ]

    BTW, to generate simple data access service you need nothing more than method declaration and query string strig:interface Users{@Query "SELECT count(*) > 0 FROM USER WHERE user_name=$1, password=$2 "boolean authenticate(String userName,String password);}It is possible to generate code for EJB,JDO,Hibernate,LDAP or OODBMS without importing any API.
    That being so, is it best that EJB invent it's own query language? Did EJB 3 consider JXPath?
  182. Off topic, SOA[ Go to top ]

    Yeah, this is the sort of thing I was thinking about. Why can't I buy BEA's container, IBM's transaction service and use an open source persistence service? IMHO in this sort of SOA world the service quality would improve along with the flexibility of the system.
  183. Off topic, SOA[ Go to top ]

    Yeah, this is the sort of thing I was thinking about. Why can't I buy BEA's container, IBM's transaction service and use an open source persistence service? IMHO in this sort of SOA world the service quality would improve along with the flexibility of the system.
    I am not EJB 3 expert, but I use this way to implement my "procedures and structs"
    and I use it for "mission critical" projects (try google, I will not use this form to promote my software). I am not O/R expert, I have used it for toys only, and tried to ask
    questions about its value. Ansevers are "by a book about JDO, JDO generates SQL better than average developer". Why do I need to generate declaratyve,standard languge to access RDBMS with " JAVA like", "OOP language ", invented by JDO experts. How can serious people trust it and after all experiments. But I do not say EJB,JDO or Hibernate is bad, I this dicussion shows it has no value, but it is very popular and it must be possible to sell it.
  184. Hibernate rules[ Go to top ]

    But the EJB vendors like IBM/Oracle/BEA have tried to kill JDO, to try and stop it from being made available.
    I really don't understand this rampant paranoia either. If we follow your reasoning, Hibernate shouldn't even exist since not only is it not J2EE, it is not backed by any big company and it's not even a JSR (JDO satisfies two of these three criteria).If a spec or product is good and fills a need, it will succeed, and no big corporation will ever be able to change that.-- Cedric
    And if a spec sucks (read Entity Beans), but has enough vendors behind it, then it continues to stumble forward like a zombie, for years and years.
  185. Backing a position[ Go to top ]

    Hi Cedric
    I am really tired of the aggressivity displayed by certain people on this thread.
    I won't presume the above was aimed at me in case I am then accused of being paranoid.

    I will say that I am backing a technology in which I have a lot of faith. I am engaging EJB 3.0 advocates as appropriate, and I am trying not to become aggressive towards individuals with whom I disagree.

    For months the JDO community had to tollerate shouting matches in which Hibernate was unilaterally promoted as the bees knees, often by people stating opinions but with little expression of technical merit. With substantial interest in JDO, and with a good quality set of features the community has been asking for in JDO 2.0, I believe we have earned the right to back our position, even if it is a position with which you disagree.

    Kind regards, Robin.
  186. Hibernate rules[ Go to top ]

    I have been reading this thread (and the JCP voting thread) with a great deal of interest over the last couple of days. I would like to espeicially thank Robin Roos, Dave Jordan, and Abe White for their rational and professional factually based arguments in the face of a lot of misinformation. Well done gentlemen.
    Hibernate may be good, and Gavin can be honored for having developed an ORM that people like and that is distributed for free. I am sure there are a number of people using it because it is free.
    Yes Dave, this is something few people here talk about. In fact, I would posulate that the fact that Hibernate is free is the primary reason that most people use it. For one the price can't be beat. Also, in a lot of organizations it is easier to bring in a free product in to the development environment then one the requires licensing, etc.
    Hibernate may be good. But there are a number of people that have been posting here, lodging complaints and criticisms against JDO, and it is very clear that they really don't know JDO. This even includes Gavin King ...
    Again, well said.
    There are topnotch ORM people at the JDO vendors too. Gavin is not the only person in the world that understands ORM.
    Gotta' agree. I have used two JDO implementations extensively (Kodo JDO & JDO Genie) and they are top notch ORM centric implementations. I have flirted with other ORM implementations such as TopLink and CocoBase in a past life, and I have to say, for many reasons JDO fits my needs better.
    I have yet to meet someone who used JDO on a project and then decided never to use it again. Once people use JDO, they love it and don't want to use anything else.
    I architect enterprise applications for a living and on my last project we used Kodo JDO. And you are right we loved it! The main advantage of JDO is that if you develop true OO applications that have behaviourly complete domein models then it fits this mode of development wonderfully.The JDO 2.0 spec will be out in a couple months, with commercial implementations right behind that.Cannot wait. JDO 2.0 EG please keep up the good work and don't let the political self interest of a few of the big players deter your from your outstanding work!
  187. Hibernate rules[ Go to top ]

    Hibernate may be good, and Gavin can be honored for having developed an ORM that people like and that is distributed for free. I am sure there are a number of people using it because it is free.
    Yes Dave, this is something few people here talk about. In fact, I would posulate that the fact that Hibernate is free is the primary reason that most people use it. For one the price can't be beat. Also, in a lot of organizations it is easier to bring in a free product in to the development environment then one the requires licensing, etc.
    I'm not so sure of that. There are plenty of free ORM outhere.
    The primary concerns of my corp in its Hibernate choice (1 year old) compared to other ORM implementations were :
     - every single need we had was covered by Hibernate in an elegant way,
     - damn good documentation,
     - damn good support,
     - having sources make devs faster,
     - happy developpers,
     - happy architects,
     - and of course less expensive than the leader at that time Toplink (believe me this was not our main concern)
    Primary concerns against Hibernate (still 1 year old, before Gavin and Christian joined JBoss) :
     - no commercial support
     - no "Big Blue"-like guarantee (This one was pretty big)
  188. Hibernate rules?[ Go to top ]

    Thanks for adding your opinion, although that is all it is.

    Three JCP members voted against JDO, one member abstained, and twelve voted for JDO. So where do you get "most"?

    I'm pleased you have respect for Gavin. Many of us do. But you claim that one person writing a spec and a product is necessarily better than a group of people sharing their diverse experiences? Yes, Gavin has much experience in this field (persistence). So do the influential engineers in each of the organizations which implement JDO.
    Hibernate will always be better than any JDO version I think.
    Thanks for letting us know. Those who hold you in esteem will no doubt give your expressed opinion significant credence. But the days of persistence technologies holding sway because a handful of advocates always shout that one is better than the others is over.

    The JDO 2.0 and EJB 3.0 debate of the last seven days has presented a wonderful opportunity for members of the JDO community (users, consultants, experts) and other commentators to provide high quality about JDO to an incredibly large audience. Three threads in particular have been extremely well subscribed. And up until now the discussions have been largely free from the abject chanting of "Hibernate is better"-like slogans.

    By the way, were you at the TSS Symposium in Vegas?
  189. Hibernate ru13z?[ Go to top ]

    Robin: I'm pleased you have respect for Gavin. Many of us do. But you claim that one person writing a spec and a product is necessarily better than a group of people sharing their diverse experiences? Yes, Gavin has much experience in this field (persistence). So do the influential engineers in each of the organizations which implement JDO.

    Hibernate, like a lot of open source projects conceived in frustration with a market full of useless software, quickly managed to solve a lot of real-world problems. I definitely know companies that are quite pleased with Hibernate.

    I also know companies that strongly dislike Hibernate, having used it. It's always hard for me to tell when it's the software being used (Hibernate) or the software using it (the application) that is responsible for both the accolades and the criticism.

    I want to hear from more people that have used both, though. There are a few that pop up, but most people like Hibernate or JDO either because it's all they've ever used or (probably more often) they haven't used either but have a strong opinion based on random blog entries and industry pundits.

    (Actually, on that point, have you used Hibernate, Robin? What is your take on it if you have?)

    There's no way that either Hibernate or JDO will disappear ... too many companies are using them both, and even with EJB 3.0 in the mix, that's a manageable number of solutions to ORM. What I'd like to see though is more information that shows the strengths and weaknesses of each. Performance and scalability, for example. Ease of development. Portability (in the case of JDO.) These are things that I'm interested in.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  190. Hibernate ru13z?[ Go to top ]

    Portability I can address. I have written JDO application code, code that has worked without change, across 5 JDO implementations, including one object database and four relational JDO implementations, and across 3 underlying RDBMSs. Besides the OR mapping metadata in XML files, and a couple of properties in my JDO property file, the Java code works fine across all these implementations. With JDO 2.0, the OR mapping metadata in the XML files will be the same too. JDO was architected to be binary compatible. You can even use the same persistent Java class files in the same JVM with multiple JDO implementations. It was designed to support this.
  191. I've implemented an application using both JDO and Hibernate and I have started to write up my experiences: http://chris-richardson.blog-city.com/
  192. Had a look at your code. please create and compile the JDOQL query in an initialization block. By doing so you will avoid compiling the JDOQL each time findRestaurants executes.
  193. Here I have got my information from (in German):

    http://www.javamagazin.de/itr/news/psecom,id,15070,nodeid,10.html
  194. Here I have got my information from (in German):http://www.javamagazin.de/itr/news/psecom,id,15070,nodeid,10.html
    you should have read the article, then:

    <em>Weitere Unternehmen und Organisationen, die für den JDO 2-Standard gestimmt haben, sind die Apache Software Foundation, Apple, Caldera, Fujitsu, Hewlett-Packard, Iona, Nokia und SAP
    </em>

    (for the non-german speakers, it mentions that Apache Software Foundation, Apple, Caldera, Fujitsu, Hewlett-Packard, Iona, Nokia und SAP all voted FOR the spec.)
  195. Don't forget that Sun and Macromedia also voted for JDO 2.0. Only Oracle, IBM and BEA voted against whilst Borland abstained.
  196. Had a look at your code. please create and compile the JDOQL query in an initialization block. By doing so you will avoid compiling the JDOQL each time findRestaurants executes.
    You make an interesting point. However, the two JDO implementations that I've used do not require the application to explicitly compile and cache the query. They do that automatically.

    I would be extremely reluctant to use a JDO implementation that required the application to do what you are suggesting. To much added complexity particularly if the application is generating queries dynamically....
  197. Had a look at your code. please create and compile the JDOQL query in an initialization block. By doing so you will avoid compiling the JDOQL each time findRestaurants executes.
    You make an interesting point. However, the two JDO implementations that I've used do not require the application to explicitly compile and cache the query. They do that automatically.I would be extremely reluctant to use a JDO implementation that required the application to do what you are suggesting. To much added complexity particularly if the application is generating queries dynamically....
    Yep, they do it automatically. Each time you enter findRestaurants, the JDOQL will be automatiaclly compiled by the implementation. that is because you create a new Query inside the findRestaurants method. If you take the following block of code OUTSIDE the findRestaurants methods, then you will be able to take advantage of the caching you mentioned.

    <code>
    PersistenceManager pm = PMRegistry.getPM();
            Query query = pm.newQuery(JDORestaurant.class, QUERY_STRING);
            query.declareVariables("JDOTimeRange tr");
            query.declareParameters(
                "String zipCode, int day, int hour, int minute");

    </code>

    The point of creating a parameterized query is precisely so you DO NOT have to create the query each time you want to use it. BTW, I think it's fantastic that you are making a productive post that benefits everyone reading the thread. Keep up the good work!

    -geoff
  198. Comparing Hibernate and JDO[ Go to top ]

    OK, apparently many implementations cache the query inside the PM, but for portability, it is very simple to move the creation of the parameterized query into initialization code. For the implementation you are using this will at least cut a few lines out of your loop :-) But you're right. If you are sure your implementation caches the query in the PM, then there is little need for the optimization I suggested.

    -geoff
  199. Geoff,

    Pre-compiling the query can be an optimization for some implementations, but is not at all necessary -- Kodo, at least, reuses query parse information even if you just create the query anew using the PersistenceManager.newQuery() method every time.

    -Patrick

    --
    Patrick Linskey
    SolarMetric Inc.
    http://solarmetric.com
  200. Hi Geoff and Patrick
    Pre-compiling the query can be an optimization for some implementations, but is not at all necessary -- Kodo, at least, reuses query parse information even if you just create the query anew using the PersistenceManager.newQuery() method every time
    JDO Genie has exactly the same optimization. This is a fairly obvious thing to do especially for implementations like JDO Genie and Kodo that cache query results as well.

    Cheers
    David
    www.jdogenie.com
  201. I've implemented an application using both JDO and Hibernate and I have started to write up my experiences: http://chris-richardson.blog-city.com/
    Thanks Chris,

    A great read! I am extremely familiar with (and fond of) JDO, but I have little experience with Hibernate. I'm sure that many others in this discussion have a similar situtaion in that they have experience with one and not the other.

    So thanks for the info, looking forward to your next installment.
  202. Yes, I have proved it many times for myself too, simple operation (Ok, it is not a procedure) and trivial model looks equal, I can use any tool to implement it and see no difference, so looks like difference is more political and it is more about buzzwords.
  203. Cameron :
    There's no way that either Hibernate or JDO will disappear ... too many companies are using them both, and even with EJB 3.0 in the mix, that's a manageable number of solutions to ORM. What I'd like to see though is more information that shows the strengths and weaknesses of each. Performance and scalability, for example. Ease of development. Portability (in the case of JDO.) These are things that I'm interested in.
    And these are the things that really matter when you get past the small project stage. I wonder if we should think of Hibernate/JDO/SDO/EJB/JDBC simply as a style or pattern decision for using persistence in our applications. At the end of the day, getting the data in and out of the persistent store is fundamentally what matters. The rest is [really valuable] gravy.

    In his talk on Geronimo at TSSS, Jeremy Boynes mentioned the approach of implementing JDO, EJB, et al as an API on top of his TranQL framework, allowing cache-coherant access to data independent of the application API. Maybe this notion should be called "EDO" - "Ecumenical Data Objects" - one place to focus on performance and diversity of the backing store, and freedom for application API to fit taste and style.

    - geir

    P.S . Has anyone compared using these technologies for their apps and is willing to share some performance numbers? I choose to Hibernate for ease-of-use reasons for my small projects but I have no clue how it will scale when pushed.... (I haven't used JDO yet)
  204. ORM sucks. I like cheese.
  205. Hi,
    it seems that subject was stir up
  206. Hi,
    it seems that subject was stir up...

    IMHO EJB3 and JDO don't make a war, but Sun should join the efforts by integrating these standards in this manner:

    - EJB3 is a standard with target enterprise applications and however beans reside in a "heavy container". EJB3 standard should contain more concepts and leave to the implementation details. EJB3 may use JDO as implementation. Reference Implementation shall do it.
    - JDO2 should allow the implementation of full EJB3 specs (if I'm not wrong be enough map EJBQL to JDOQL)
    - Hibernate could be a JDO implementation ;-)

    And they'll living happy ;-)

    bye,
    Luca Garulli
    Orient ODBMS
    www.OrienTechnologies.com
  207. Back to the Basics[ Go to top ]

    Why not use JDO2 to implement the persistence layer for EJB3. Why do we need a seperate query language and implemenation for EJB3.
  208. Both Gavin King and the TopLink team at Oracle joined the JDO expert last fall while we were working on JDO 2.0. We started JDO 2.0 this past August. Now, in this thread, we have heard that the EJB 3.0 work started 9 months ago, which is also around August. The TopLink team was at the August JDO meeting, Gavin joined in later. The biggest "contribution" made by the King/TopLink pair was to convince the JDO expert group that JDO's binary compatibility feature should become optional in JDO 2.0. They said they could and likely would adopt and implement JDO 2.0 if we dropped the binary compatibility capability. We made it optional for their benefit, and the existing JDO vendors said they would continue to support the binary compatibility option. Some of us in the group, including myself, were opposed to this, seeing it as weakening the standard. But the JDO vendors assured us that they would continue to be binary compatible.

    Besides some brief discussions with the expert group relative to attach/detach functionality, we did not really hear much else from Gavin. But members are not required to be actively vocal throughout the process, yet we were curious why he seemed to "disappear". I was contacted by several people who stated that Gavin was telling people that he was having to teach the JDO expert group how to do OR mapping, that they needed his assistance. That is simply not true, at all. He only said a couple of things relative to OR mapping during the whole process, and it was simply stating how they did things in Hibernate.

    Originally, Marc Fleury was opposed to JDO, speaking out against it. But when he came to my town to give a talk about J2EE, I asked about JDO. He criticized JDO during his talk and kept referring to it as Castor. After the presentation I introduced myself to him, as a member of the JDO expert group and author of the O'Reilly book on JDO. I also informed him that Castor is not the JDO API, that this was a common misconception because of how the Castor folks named the product. After that, Fleury learned more about JDO and became a fan of JDO. Furthermore, JBoss announced they were going to have their own JDO implementation. Also, I was contacted by JBoss and offered a job to help develop their JDO implementation. So it appeared that JBoss was backing JDO.

    Then it became known last August that Gavin King had been hired by JBoss. This seemed to fall in line with Gavin's statements that he was going to support JDO if we dropped the binary compatibility. Since JBoss had already started distributing a JDO implementation, we wondered whether JBoss was going to have two JDO implementations, or that their own internal efforts of developing JDO had failed and that they were going to start with Hibernate as the basis for their JDO implementation.

    Now, Jboss and the EJB 3.0 expert group have announced they will go with Hibernate, and at the same time they are criticizing JDO, criticisms that have not held up to the truth about JDO, expressed by members of the expert group in this thread.

    Meanwhile, the JDO spec lead at Sun has shared the JDO 2.0 spec with the Sun EJB 3.0 and J2EE expert groups, so that they could see what we had accomplished and he also asked for their input and consideration of adding JDO as an alternative persistence mechanism.

    And this past Friday evening, due to the recent EJB 3.0 announcements, Oracle formally withdrew its participation in the JDO expert group via an email to the whole JDO expert group, citing recent EJB announcements as the reason. Their technical representative also admitted that he was also on the EJB 3.0 expert group.

    Several JDO expert group members known for their involvement with JDO tried to join the EJB 3.0 expert group, but they were turned down.

    The JDO expert group has been very open to input, even from entities that had competing technologies (Hibernate, TopLink). We have also shared our interim work with Sun folks doing J2EE and EJB. But it is clear that now that they do not want to cooperate with the JDO community, even though we have made every attempt to include them in our efforts. We even told Oracle that they did not have to quit the JDO expert group after they withdrew on Friday.

    JDO 2.0 is moving forward and a public draft spec should be released very soon. Its support for standardized OR mapping, extensive enhancements to the query language, and support for attach/detach functionality will provide a very compelling API that will gain much favor among developers. I believe the EJB folks now see that JDO is a major threat to their own efforts, which is why Oracle, IBM, and BEA voted against the JDO JSR. But JDO 2.0 passed in the voting process and it will soon become available to everyone.
  209. Hi Dave J.,

    Thanks for the history on the Gavin King, JBoss, Oracle, etc.. interaction with the JDO community. Very interesting stuff. It's a shame when politics get in the way of great technology (which JDO is).

    Regardless, I will continue to use JDO successfully on my J2EE projects. And wait in eager anticipation for the JDO 2.0 spec and the vendor implementations that follow. I'm sure many others out there are doing the same.
  210. a story from real life[ Go to top ]

    That was a great story. Thanks!
    The ring of truth..wish I could say the same of all the other posts.
    And the story goes on, it surely is entertaining!

    I wonder what IBM, Oracle and BEA will try the next time, to keep their position to continue to milk their customers.

    Regards
    Rolf Tollerud
  211. Hi David,

    Thanks for an interesting history of the story so far from the JDO expert group point of view. I have actually written up a few thoughts on my own experience as an independent member of the EJB expert group here. The page on POJO entity beans is particularly relevant to your story.

    The most important point is that the EJB expert group /did/ take a serious look at the options, including adopting JDO as our new persistence model. The discussion was lengthy, detailed, and technical. We eventually decided that an approach based on standardizing ORM was a better way to achieve our design goals.

    I was aware at the time that there were some commercial interests at stake in the technical decision, just as I am aware now that there are commercial interests at stake in this thread. But I can assure you that the decision had to be justified in the interests of the full J2EE community, and we did achieve consensus, including from independents like me with no agenda for or against any JDO or EJB vendor.

    I remain a fan of both JDO and EJB technology. Although they will be targetted at different cases they will both continue to be developed and used. Let's all move forward now, remembering that a little healthy competition and choice between standards is not such a terrible thing after all.
  212. I have actually written up a few thoughts on my own experience as an independent member of the EJB expert group here. The page on POJO entity beans is particularly relevant to your story.The most important point is that the EJB expert group /did/ take a serious look at the options, including adopting JDO as our new persistence model. The discussion was lengthy, detailed, and technical. We eventually decided that an approach based on standardizing ORM was a better way to achieve our design goals.
    Thanks for the interesting read, Scott. I have no doubt as to your integrity or that of most of the EJB expert group. Unfortunately, I think the evaluation of JDO by the expert group was either based on misconceptions about JDO, lack of information about standardized ORM features in JDO 2, or, mostly likely, both.

    I say this because, while your blog implies the EJB 3 expert group dismissed JDO to make a solution targeted only at relational DB users, EJB 3 doesn't offer any advantages over JDO 2 in relational persistence. Both offer the same relational features: standardized mappings to relational DBs via annotations or XML files, direct SQL queries, access to the JDBC connection. The query languages are different, but as I tried to point out in my response to Gavin, functionally equivalent. JDO could easily be made to support EJBQL if it had to.

    It is true that JDO supports alternative data stores, and in fact many users happily use JDO front-ends to ODBMs, legacy systems, XML files, etc. But the JDO community recognizes that the majority of JDO users are accessing relational databases, and we have designed the JDO 2 spec accordingly. ORM features are standardized, without dropping support for other stores. This seems to me to be the best of both worlds.

    And even though I feel using JDO for persistence in EJB 3 would certainly have been best for the Java community, I understand that the expert group is free to develop its own persistence solution (though I don't see the rationale). What really disappoints me is that a very few members of the group, whether out of ignorance or maliciousness, feel the need to spread misinformation about JDO in order to promote their own products. This has been going on since the JDO 1.0 spec was first finalized, and while technical arguments can be informative and invigorating, constantly dispelling misinformation is just tiring.
  213. Hi Scott

    The following is from your EJB 3.0 POJO-Persistence page.
    One of JDO&#8217;s key strengths is that it is datastore-agnostic, meaning your objects persist equally well to OO databases and to relational databases. But trade-offs in design are ever-present and my judgement is that JDO must pay a price for this flexibility
    Are you specifically aware that JDO does pay a price, are you specifically aware of what that price is, or are you merely presuming that an approach such as JDO's inherently must be a "lowest-common-denominator" and that further understanding is not required?

    Under the JCP, JSR-220 has a remit to simplify development of EJB components, but does it have a remit to redefine transparent persistence (sorry - "POJO-persistence") in the light of existing JCP-ratified standards (JDO 1.0.1)?

    Can you articulate the difference between an "ORM" solution and an implementation of JDO with standardized object-relational mapping?

    You and I occupy similar positions in our expert groups. We appreciate the information which you have provided and continue to provide to the community. However, with the JSR-220 group choosing between Option 2 and Option 3 it would have been common courtesy for JDO to have been adequately represented in the discussion, and so far nothing indicates that to have been the case.

    Thanks for crediting JDO on your own FAQ page.

    Kind regards, Robin.
  214. I believe the EJB folks now see that JDO is a major threat to their own efforts, which is why Oracle, IBM, and BEA voted against the JDO JSR. But JDO 2.0 passed in the voting process and it will soon become available to everyone.
    (Though cant speak for the other vendors,..) can see no reason why JDO would be a threat to EJB. Surely we dont believe it is.

    At the end of the day both are APIs and need actual implmentations underneath. And both can fairly easily be mapped onto each other- JDO could conceivably work on CMP and CMP containers could use JDO for underlying persistence. Given this, as someone mentioned earlier in this thread, a little healthy competetion is surely good for the community. :-)

    Cheers,
    Ramesh
    http://www.pramati.com
  215. Dear David Jordan[ Go to top ]

    Besides some brief discussions with the expert group relative to attach/detach functionality, we did not really hear much else from Gavin. But members are not required to be actively vocal throughout the process, yet we were curious why he seemed to "disappear". I was contacted by several people who stated that Gavin was telling people that he was having to teach the JDO expert group how to do OR mapping, that they needed his assistance. That is simply not true, at all. He only said a couple of things relative to OR mapping during the whole process, and it was simply stating how they did things in Hibernate.
    Dear David Jordan,

    Please take your personal smears elsewhere. I have never, ever told anyone that I "was having to teach the JDO expert group how to do OR mapping". That is an absurd claim. I may have pointed out to a couple of people (in private) that some of the big new features of JDO2 looked almost as if they might have been influenced by Hibernate, since we have had them for 2 years now. However, if ever I made any comments at all about the JDO EG, which was rarely, and never in public, I said exactly the opposite: that the JDO EG viewed me as an "outsider" and wasn't really interested in my contributions.

    I would also point out that there were months between me "giving up" on the JDO group, and joining the EJB3 EG. I was not responsible for the decision to not adopt JDO into EJB3, and, guess what: I am just not that powerful! People look at JDO and make their own decisions.

    Thanks. Bye.

    P.S. To outsiders reading this thread - please understand that almost everything written here has been written by someone with a direct financial interest in the success of JDO or EJB3 (myself included). Look at the technology and make up you own minds. It should be perfectly obvious what the attacks on my personality (an absolutely irrelevant issue) are motivated by.
  216. Dear David Jordan[ Go to top ]

    P.S. To outsiders reading this thread - please understand that almost everything written here has been written by someone with a direct financial interest in the success of JDO or EJB3 (myself included). Look at the technology and make up you own minds. It should be perfectly obvious what the attacks on my personality (an absolutely irrelevant issue) are motivated by.
    Yes, I hate to see it too, technology and bussines are not personal.
  217. JDO2 using ideas from Hibernate[ Go to top ]

    Hi Gavin
    I may have pointed out to a couple of people (in private) that some of the big new features of JDO2 looked almost as if they might have been influenced by Hibernate
    Certainly attach/detach is influenced by Hibernate. The whole idea of making binary compatibility optional was introduced so Hibernate and Toplink could become JDO compliant without having to use bytecode enhancement. The JDO 2 expert group is not operating in a vacuum inventing things out of thin air.
    that the JDO EG viewed me as an "outsider" and wasn't really interested in my contributions
    I am sorry you feel that way. The EG really wanted you and Toplink on board.

    Cheers
    David
    www.jdogenie.com
  218. Strongest survives[ Go to top ]

    P.S. To outsiders reading this thread - please understand that almost everything written here has been written by someone with a direct financial interest in the success of JDO or EJB3 (myself included). Look at the technology and make up you own minds.
    I agree. If JDO version XYZ will be so much better than Hibernate has ever been then fine; we'll give it a go as soon as it's ready.

    I can see perfectly well why EJB specification lead chose to use Hibernate (and Spring) as their template. JDO being equally good in some point of future was probably not enough. Hibernate has been proven to work, it's easy, it's widely adopted and it has all the ORM functionality that developers need. HQL is a huge leap from current EJB QL.

    JDO 2.0 might be The Next Big Thing. Who knows. But until I see a finished spec and some really good implementation, I'll be using Hibernate.
  219. Strongest survives[ Go to top ]

    I can see perfectly well why EJB specification lead chose to use Hibernate (and Spring) as their template.
    It seems like EJB 3 is more democratic than other JSRs. Maybe the JCP is improving.
  220. Dear Gavin King[ Go to top ]

    I did hear from several sources that you had been claiming credit for teaching the JDO expert group to do OR mapping. But I'll admit this could have all been false stories spread through the grape vine. But that story WAS spreading.

    I don't think the expert group treated you as an outsider. There was some "reaction" to your initial participation, because it became clear in early discussions that you were not that familiar with the current JDO spec. But that's OK, you were busy with Hibernate, being a JDO expert was not a requirement for participation. We really valued your input on attach/detach, since you had already had success with this functionality in Hibernate. And we dropped binary compatibility primarily so that you would support JDO in Hibernate, which you told us you would do if we dropped binary compatibility. So we definitely did value your input. True ,there were periods of debate, but we have got some 20 JDO implementations now and there is a limit to the number of concessions we can make to one new vendor joining the JDO expert group.

    Then a few months past by and we did not hear a word from you. People were actually wondering, "what happened to Gavin". We wanted your participation, yet you seem to disappear. I don't know when you joined EJB 3. That's really not relevant. I really think the EJB expert group chose Hibernate because of some of its similarities to JDO, but they also chose it because it was not JDO. Some of those involved in EJB have been against JDO for quite a while.

    I have no issues with you or your work. You and I had shared several private email discussions during your time participating in the JDO expert group and you definitely got me interested in learning more about Hibernate.

    My issues are with the folks at Sun/IBM/Oracle/BEA who are trying real hard to disrupt JDO's success. Let the market decide which technology is best, don't let these big companies force something down our throats.
  221. Some of those involved in EJB have been against JDO for quite a while.
    WebLogic could be tweeked to use TopLink as an alternative CMP engine. But I don't think EJB has a standard way to switch amongst CMP engines. Wouldn't it be nice if EJB's CMP had standard pluggability? An application developer could decide whether to map his entity beans to JDO or default CMP. Maybe the developer wants to persist his entities to an XML database. Maybe he wants to use XPath queries rather than SQL. The standard entity lifecycle should be abstract enough to transact with non-relational stores. EJB 3 misses this.
  222. <blockquoteWouldn't it be nice if EJB's CMP had standard pluggability? An application developer could decide whether to map his entity beans to JDO or default CMP....EJB 3 misses this.Yes this would be cool for clients but not for the vendors.
    This is one of the main reasons that big app.server vendors (including JBoss) do not want to adopt JDO, because it is poses great risk to them...since their client could potentially switch vendor...

    Also, from technical point of view, if EJB3 will be adopting pluggable persistence then it will eventually evolve into JDO anyway...since that is the framework already in place for pluggable persistence.

    The issue with EJB3 vs JDO2 is purely political (driven by greed of the corporations and some of the individuals)

    Technology wise, my personal preference is JDO.
  223. Some of those involved in EJB have been against JDO for quite a while.
    WebLogic could be tweeked to use TopLink as an alternative CMP engine. But I don't think EJB has a standard way to switch amongst CMP engines. Wouldn't it be nice if EJB's CMP had standard pluggability? An application developer could decide whether to map his entity beans to JDO or default CMP. Maybe the developer wants to persist his entities to an XML database. Maybe he wants to use XPath queries rather than SQL. The standard entity lifecycle should be abstract enough to transact with non-relational stores. EJB 3 misses this.
    It looks like the EJB3 folks have lost focus on the problem, at least
    wrt entity beans. EB unpopularity, I feel, has more to do with design
    flaws (no inheritance, pluggability, persistence combined with
    distribution, granularity issues etc.) than their complexity. With EJB3,
    the focus is too much on simplicity at the expense of flexibility. To
    focus solely on ORM and ignoring XML databases, LDAP etc. is a huge backward
    leap. For once, Microsoft can claim to be technically superior and forward
    looking (with their ADO approach) than Java/J2EE!

    Regards,
    Kalyan
  224. Some of those involved in EJB have been against JDO for quite a while.
    WebLogic could be tweeked to use TopLink as an alternative CMP engine. But I don't think EJB has a standard way to switch amongst CMP engines. Wouldn't it be nice if EJB's CMP had standard pluggability? An application developer could decide whether to map his entity beans to JDO or default CMP. Maybe the developer wants to persist his entities to an XML database. Maybe he wants to use XPath queries rather than SQL. The standard entity lifecycle should be abstract enough to transact with non-relational stores. EJB 3 misses this.
    It looks like the EJB3 folks have lost focus on the problem, at least wrt entity beans. EB unpopularity, I feel, has more to do with design flaws (no inheritance, pluggability, persistence combined with distribution, granularity issues etc.) than their complexity. No, it's just that nobody is interested.

    WebLogic's CMP container has been pluggable since the very early days of WLS4 if memory serves(<persistence-type> tag for those who know). We have a public API to allow plugging into our CMP engine so that users and ISV can write their own CMP implementation if they want.

    It sounded like a good idea at the time.

    Hardly anyone has ever used it and it's pretty much useless nowadays, although we still keep it around for backward compatibility.

    As for why nobody is interested, I have several theories but that's beside the point right now.

    --
    Cedric
  225. Great post.

    Please forgive my simplistic ramblings, but...

    Decoupling services from the container is *the* key issue, in my book. I like Hibernate, and I like JDO (particularly Kodo), and apply them to different scenarios as requirements differ. Hibernate lets me tie much more closely to the schema; JDO to the model. Hibernate is quicker out of the gate; Kodo seems stronger in the enterprise. The decision to tie EJB3 to a nonstandard Hibernate rather than allowing a pluggable persistence strategy cuts right to the heart of what's wrong with EJB as a whole (of course, EJB 2.0 CMP had many well-documented holes beyond the more global EJB issues, but let's focus for a second.)

    Further, if it's successful, EJB3 will set persistence alternatives back by potentially choking out highly qualified competitors in the space, all because they don't choose to build a full container.

    In general, the way that we produce, package, and consume services is *the* issue. And it's one of the things that's made Hibernate so effective. I can plug and play with the transaction strategy, the dialect, data sources...I can adopt the tool to the task at hand.

    I had abandoned EJB shortly after writing Bitter EJB. I was cautiously optimistic about EJB3, but discussions like these scare me. Given the alternative, I think I'd much rather stick with lightweight containers like Spring, and choose the best services for the job, from Kodo and Hibernate.

    Please. Don't make me eat the whole elephant again.
  226. Not only that, but ADO has very good support for multi-dimensional structures. ADOMD, which uses the same object model as ADO, along with MDX, is the most popular method for accessing OLAP cubes programmatically.

    There're no standard Java API implementations for accessing multi-dimensional data, and JOLAP as a spec is way behind MS MDX, ADOMD, and XMLA.
  227. Dear Gavin King[ Go to top ]

    Looks like experts can not protect transparent persistence from evil procedures and started to talk about persons.
  228. Back to technology...[ Go to top ]

    Gavin commented:
    Look at the technology and make up you own minds.
    Indeed I agree.

    It is unfortunate that a small item regarding Gavin in David's comments has been seized upon. Oracle has already expressed their intent to withdraw from the JDO 2.0 process (although personally I see nothing to necessitate this), and it would be unfortunate if personal friction caused Gavin to do the same. The communication channels afforded independently by the membership of Mike Keith (Oracle) and Gavin King (JBoss Group) have been extremely useful, hopefully to all parties. But let's put that behind us and talk technology instead....

    I maintain that:
    • Abe White's rebuttal of Gavin King's technical critique of JDO remains largely un-addressed.
    • JSR-220 does not have a mandate from the JCP to compete directly with JSR-12 (JDO 1.0.1), and should be censured by the JCP for taking the "Option 3" which Scott Crawford identified here.
    • The JSR-220 spec lead's comments regarding EJB 3.0 have validated IoC containers (EJB 3.0 adopts IoC), and validates both the JDO and Hibernate approaches (through the removal of CMR for the new "POJO-Entity Bean"). EJB was becoming increasingly irrelevant prior to this announcement, and the validation so offered might render EJB 3.0 even more irrelevant by the time it is available.
    • The "credibility gap" faced by EJB as a technology is actually much wider than that faced by JDO (for the incorrect perception that it somehow favours ODBMS technology at the expense of relational capabilities).
    • The JDO Expert Group members are fundamentally pleasant people with breadth of understanding and depth of expertise. We have a track record of listening to the community. We have, however, learned from the "Make Hibernate the Standard" lobby on TSS that we must excel in debating as well as in technology, hence the debates which have given rise to 500 TSS posts regarding JDO this week. We should not have to apologise for being passionate about JDO technology.
    • The game is actually about mind share. Hibernate has had the advantage here for a while, but perceptions around the Hibernate/JBoss/EJB party are making the game a little more even in that regard. JDO currently lacks a production-proven Open Source implementation. I had hoped that Hibernate might fill that space, and there is certainly still scope for that to happen.
    Any offers?

    Kind regards, Robin.
  229. Back to technology...[ Go to top ]

    Hi Robin,

    What do you think about OJB? It's incredible that nobody talk about this framework.
    OJB could become the production-proven Open Source implementation for JDO
    Why not?

    Cheers

    Dawn
  230. Back to technology...[ Go to top ]

    Hi Dawn

    As the official Apache ORM project I believe OJB is very important. I gather that work on a spec-compliant JDO 1.0 implementation has been curtailed in favour of JDO 2.0 compliance. If OJB could put JDO 2.0 features into the open source community then that would be fantastic.

    Is Geronimo expecting to "play nicely" with OJB? This combination could be an extremely credible contender against the JBoss stack.

    Kind regards, Robin.
  231. Back to technology...[ Go to top ]

    What about Speedo from ObjectWeb? I was looking through their version history after writing the reply to Dawn. It appears that Speedo might be very close to JDO 1.0 compliance. Can anyone comment further?
  232. Here it goes: JPOX is an open source JDO implementation full JDO 1.01 compliant (passed JDO TCK tests) that supports many optional JDO 1.01 features and some features that will be included in JDO 2.0.

    If you want to know more about JPOX, please go to http://www.jpox.org

    We are also recruiting developers!!! :)
  233. Back to technology...[ Go to top ]

    In any case,it's a real occasion for OJB to leave the shade of Hibernate.
    I believe that I'll begin immediately my book "OJB in action" ;-)

    Thanks

    Dawn
  234. Back to technology...[ Go to top ]

    Dawn / Eric, do you also get the feeling that as the sun rises on JBoss group and their influence in EJB 3.0, so the shadow cast by JBoss and Hibernate technology is shortening?

    I firmly believe that JDO's datastore agnosticism, and the fact that it is an open yet focussed standard implementable by all who choose to do so (no need to implement an EJB stack also) will yield a seismic increase in competitiveness within the persistence sector. That is good for the open source JDO implementations, good for the commercial JDO implementations, and ultimately good for the customer who must choose whether, and how much, to pay.
  235. Back to technology...[ Go to top ]

    Robin, your perception of reality is almost as weird as your technical opinions about data management.

    http://sourceforge.net/project/stats/index.php?report=months&group_id=40712
  236. Impressive numbers. My home page is about to clock 15,000 which is a whole 'nother ball game. It would be great if sourceforge also maintained stats on the battle for the hearts and minds of developers.
  237. Dion with oil for troubled waters[ Go to top ]

    Dion in his latest blog entries raises a few interesting points regarding EJB 3.0 and JDO.

    JDO 2, EJB 3, and the right place to standardize persistence, which concludes with a vision of a brave new world in which:
    At this point the EJB spec will just be a standardization of some enterprise services. When it makes sense, sub-specs can be created allowing us to divide and conquer. We can work on the sub-parts in parallel, and experts in those areas can work on doing the best job they can.
    Scott Crawford on EJB 3.0, which concludes:
    So, I appreciate your comments Scott, I know you made decisions on information that I don't even know about, and I am sure that you did the best job possible. I just still think that it is SUCH a shame that something couldn't have been worked out here. I know the JDO group would have worked hard with you all to make this the best for everyone.

    And there IS still time.
  238. Java is its own worst enemy[ Go to top ]

    Pardon me for jumping in. I know I'm not an established "face" around here...

    As much as I enjoy Java programming, sometimes these discussions make my head spin. No offense to Mr. King, but his biggest problem with JDO seems to be that it doesn't do things the way he'd like it done. Three major EJB vendors vote no against a "competing" technology because they're afraid of the JDO "overlap".

    Hibernate adoption being more widespread than JDO does not necessarily make it better. If that were the basis of software quality, than Windows XP is the greatest operating system of all time. I find it ironic that one of the more common arguements in favor of technologies like EJB's or Struts is widespread adoption, often coming from the same people who will say Windows being widespread doesn't make it good!

    At some point, choice is good. However, there is rarely room in the market for more than a handful of competing technologies. At a certain point, products just fade into obscurity. The real shame of it is, you have all these people busy doing things their way rather than contributing to existing standards and improving them.

    It's a twofold problem. On one side you have the maverick who believes there is a better way, and on the other side you have the person who has already promoted their way of doing things and are not inclined to change. This is largely why we have the monstrosity that is Struts and about two dozen web frameworks, some better than others, trying to displace it.

    I think it's similar on the server side. You have an entrenched community who has gotten used to using EJB's. They might be cumbersome, slow, and tedious, but you find security in understanding how to make something work. Coming along and saying "Use JDO! Use Hibernate!" is rarely a challenge, but perceived as more of a threat.

    There are some great minds behind many of these specs. It's a shame they are not working together to form an all-encompassing enterprise solutions API. All I seem to see in the Java community is division. Imagine if more resources were pooled in synergistic efforts instead.

    I keep hearing that the best will rise to the top. I keep wondering if we'll just end up with the equivalent of Windows for the server-side. Something that everyone uses but no one is really happy with.
  239. Moment of Truth[ Go to top ]

    <
    I have been watching the Java industry for last couple of years - how they
    marginalise the RDBMS technology. They know java and they want to make their
    entire world java based. So lets to the "database independent" code. Haha.

    Anyway - Just looks at the current state of EJB, JDO.

    My observation is that to be an excellent enterprise software developer - you must have good skills in (DBMS - table design, sql squeries) [do not avoid it]
    and Domain layer (Java, C#).

    Do not close you eys and hope SQL just goes away.

    Ricky
  240. I have worked with EJB:s in large projects in the financial industry since 1998. The perisistent solutions involved has been an OODB (Gemstone/J), a homemade O/R-tool based on Java code generation from XML-metadata, and a JCA-like API towards mainframe. In the first two projects EntityBeans has been under consideration, but always failed due to apparant design flaws. The most basic design flaw is to combine two utterly hard technologies in one specification; distribution with persistence.

    My architectual rationale in new projects for JDO and EJB is:

    - JDO is a standard that works as a good separator from the distribution and transaction demarcation technology provided by EJB. The requirement on JDO and EJB in combination is therefore simple; make the transaction mechanisms work togheter. (Which they actually seems to do).

    - Those who don't want to make objects persistent, but instead want to produce the highly popular "function cream" on top of a database model, should use JDBC in order not to mix up the concept of objectification of Tables and Rows with the concept of persistent objects.

    - Stateless EJB:s are wonderful to use as facades for serverside components, in which you then make the object oriented business objects in pure Java where some of them are persistent, and some not. JDO should also work wonderful for the persistent objects in such architecture. The EJB-interface of the on the other hand shall not use the object oriented approach, but shall purely be in line with a good interface design for a Service Oriented Architecture (SOA), which means usage of something like value object/transfer objects in the interface.

    JDO can be used in other tiers other than at the EJB-appserver; it can be used nicely in servlets or directly from desktop applications. Since JDO is a standard where you can use different databases in the different tiers, even though you are using the same API, it will be a good investment for the company to let the Java-developers to learn JDO. Then they can be more useful when working in different tiers. For example, in a component with Stateless EJB, the persistent of Java-objects can be done with a nice JDO-product, such as the Kodo product Abe White works with. In the Servlet arena you preferably use a OODB product like Versant for distributed and fail-over safe sessions in a clustered environment. On a client side Java-based mobile phone you might not opt for full scale transactional RDB, but perhaps more something like BerkleyDB. JDO works in all cases.

    EntityBeans is the enterprise architecht/project managers nightmare and seems to be invented by the Java competition in order to make the otherwise good EJB technology to slow down and loose focus from the real needs of the EJB standard (for example, EJB-interceptors for easy pluggability of own container code such as complementary security-techniques, or more easy deployment without the darn descriptor files, etc, etc). Today IBM, Oracle and BEA spends thousands of dollars on a technology that was born to die. I think they just fight for the technology jut because it is to embarrising to admit it was a bad economical decision on their part.

    JDO should however be a good way out for the implementors of techniques like CMP EntityBeans, when the EntityBeans ship finally sinks. Simply use a JDO implementation for the CMP implementation in order to let the legacy code live.
  241. I think JDO community need to be careful whom to put in charge of the new JDO2 spec.

    Some people (even respected and technical) can just derail the whole thing because of their "personal believes" into something else (e.g. Hibernate).

    Therefore, by sitting in the JDO2 spec body, they instead of doing positive work on the spec and be an evangelist of the technology....just throwing out FUD.

    Really embarrassing for everyone, including FUDer himself...
  242. "IT without borders"?[ Go to top ]

    Well, for all of us "what persistence technique will use in the J2EE world next year" is both interesting and amusing. Looking forward to it!

    In the meanwhile I can not hide this little perl from you,
    The Beauty Academy of Kabul

    I wonder what is the state of Java in Afghanistan?

    Regards
    Rolf Tollerud
  243. Repeating a point that I made at the Hibernate blog: Why does an O/R mapping spec like EJB 3 Entity Beans have to be part of the EJB spec? This could easily be a standalone spec that's usable in any environment, even if not adopting JDO because of its query language or other technical reasons.

    The EJB spec could simply refer to that separate spec for persistence. With it being part of EJB, no persistence tool vendor can implement the O/R mapping spec - just J2EE server vendors can. This seems to be all about politics... completely neglecting the need for O/R mapping outside a J2EE server.

    Juergen
  244. With it being part of EJB, no persistence tool vendor can implement the O/R mapping spec - just J2EE server vendors can. This seems to be all about politics... completely neglecting the need for O/R mapping outside a J2EE server. Juergen
    That's it. Developers are going to be ignored once again for the benefit of large corporations. This has been going on for years in Java world now... I'm so sick and tired of it.
  245. What do you think will happen when they finally kill JDO?

    It might be the best thing it could happen to it. They should finally kill JDO as a spec, and release a specific implementation as an open source project. Then it will finally win over EJB.

    Usually one doesn't want two open source projects that do the same thing, but since JDO's implementations are quite different from Hibernate, it might be good to have both. Different people will definitely choose differently.

    Personally I have always liked Hibernate because of its clear focus on performance and because of its mind share, but if this association to JBoss becomes more than marketing, then JDO will definitely be a good backup option.

    Guglielmo
  246. Everyone agrees. Hibernate is tempting because it's free...

    If they want to Kill JDO as a spec?
    The solution is to give to Java community a free JDO 2.0 implementation.
    Then we will see darwinism in action...

    Cheers,

    Dawn
  247. Forke Hibernate and implement a few interfaces, Will it become better ?
  248. Hi All,

    This is slightly off topic, but could anyone from the JDO 2.0 EG comment on whether or not JDO 2.0 will include standardization of Large Result Set support. This would assist in the support of "previous/next paging" of query results. In a previous project, using Kodo JDO (which has this support), I had to write the following code to keep my persistence code JDO portable:

    <code>
    // Get the extent
    Extent customerExtent = persistenceManager.getExtent(Customer.class,true);

    // Convenience method to execute the query
    Collection queryResults = executeCustomerQuery(customerExtent,customerSearchCriteria,persistenceManager);

    List resultList;
    if (queryResults instanceof List) {

        // This is always the case with Kodo JDO. Kodo implementation of List is a smart lazy loading list.
       
        resultList = (List) queryResults;

    } else {

       // Portable among all JDO implementations, but it will wind up instantiating all elements in the collection, which might be a huge number of objects.

       resultList = new ArrayList(queryResults);
    }

    </code>

    Any comments. Thanks in advance.


    </code>
  249. Hi All,This is slightly off topic, but could anyone from the JDO 2.0 EG comment on whether or not JDO 2.0 will include standardization of Large Result Set support.
    The JDO 2 query APIs include a mechanism to select a range of values instead of the full results. So, you can query for items 20-39 in a given query.

    -Patrick

    --
    Patrick Linskey
    SolarMetric Inc.
    http://solarmetric.com
  250. Hi All,This is slightly off topic, but could anyone from the JDO 2.0 EG comment on whether or not JDO 2.0 will include standardization of Large Result Set support.
    The JDO 2 query APIs include a mechanism to select a range of values instead of the full results. So, you can query for items 20-39 in a given query.-Patrick-- Patrick LinskeySolarMetric Inc.http://solarmetric.com
    Thanks Patrick. That's exactly the kind of functionality I was looking for.

    Can't wait for the release of the JDO 2.0 spec! Sorry to all for going a little off topic.
  251. Fork Hibernate![ Go to top ]

    Forke Hibernate and implement a few interfaces, Will it become better ?
    With Gavin going with JBoss, EJB3, and supporting container-based persistence,
    it may be a good idea to fork Hibernate to be JDO2 compliant (as JDO spec
    has been suitably modified to allow that). That would give Hibernate users
    the added advantage of a portable standards-based implementation. With Gavin
    going with JBoss, it is not clear how Hibernate will be evolving.
  252. Fork Hibernate![ Go to top ]

    Persons can not kill technology, Gavin is a great man and hi did a lot for transparent persistence, but emotions and persons are not interesting for me and for my customers, this fork will not be intersting for community too, if project is inspired by emotions only then I am sure it will die.
    Forke Hibernate and implement a few interfaces, Will it become better ?
    With Gavin going with JBoss, EJB3, and supporting container-based persistence,it may be a good idea to fork Hibernate to be JDO2 compliant (as JDO spec has been suitably modified to allow that). That would give Hibernate users the added advantage of a portable standards-based implementation. With Gavin going with JBoss, it is not clear how Hibernate will be evolving.
  253. Everyone agrees. Hibernate is tempting because it's free...
    By "everyone" you mean vendors of commercial JDO implementaions (JDO EG)?

    A look at how users answered "Why Hibernate was selected, what were the other options considered" proves that Hibernate was choosen for reasons other than price:
    http://www.hibernate.org/113.html?

    It is something new: failed official technologies and brilliant open source projects? Too many rewritten and deprecated specifications, lack of working stuff.
  254. Everyone agrees. Hibernate is tempting because it's free...
    By "everyone" you mean vendors of commercial JDO implementaions (JDO EG)?A look at how users answered "Why Hibernate was selected, what were the other options considered" proves that Hibernate was choosen for reasons other than price: http://www.hibernate.org/113.html?It is something new: failed official technologies and brilliant open source projects? Too many rewritten and deprecated specifications, lack of working stuff.
    Yes, things are very simple, technology reputation helps to sell sofware.
    Security, performance, scalability and cost this is usefull for enterpise, "transparent and easy to develop, designed for monkeys" doe's not.
  255. Lazy Load[ Go to top ]

    Hi
    Anyone knows how JDO, Entity CMP and Hibernate implements lazy loading?
    Thanks
    Patricia
  256. A View from the big guys ...[ Go to top ]

    Hi,

    the reply to Gavin's BLOG entry is very technical - o.k.
    What I found interesting in Gavin's posting are the non-technical aspects. Some might have seen that I was looking for a persistence solution for an app for the "big guys" who have mission critical web sites for some 10.000 + potential users - like banks, insurances and the like. These tend to be very conservative and have an inherent problem with open source software (no need to discuss this - just accept it :-))

    Now what could we choose from
    * Hibernate: for me this seemed to be the most elegant solution - BUT open source
    * JDO: Functionally o.k. - but from small vendors and not supportet by the big ones the likes of IBM
    * EJB 2.0: A deployment descriptor and anti-pattern collection :-)

    So what should we use? None of the above? So there were no really thrilling alternatives for the big users here.

    Now comes Gavin's posting and now come the comments of the people who voted on the JDO 2.0 standard. These statements read for me like we will have a
    persistence solution which is light enough in the direction of JDO and Hibernate and also supported by the big guys the like of Oracle and IBM ..
    So .. what do I do now? Go for JDO?

    This is why the technical discussion might turn out to less relevant - as the big guys go more for safety than the last corner of technical elegance.

    Just my two cents

    Wolfgang
  257. A View from the big guys ...[ Go to top ]

    This is why the technical discussion might turn out to less relevant - as the big guys go more for safety than the last corner of technical elegance.

    Big guys traditionally favour lock-in over everything else. Hence they prefer Hibernate over JDO. If you have a free thinking, liberated mind you'd choose JDO. If you don't mind being constrained by the big guys who have their own interests at heart then you'll probably choose Hibernate.

    The choice of freedom over constraint is the very reason you like open standards and open source software in the first place isn't it. Yet I hear people basing decisions based upon what the 'big guys' are dictating - come on guys, remember Microsoft? Isn't this just a case of history repeating itself but under the guise of open source software?

    Hibernate is free but provides much less freedom as a persistence technology. Straight away it rules out object databases (which actually is a 'safe' direction if you're a company that makes kazillions selling relational databases). Just look up some performance comparisons of O/R mapped solutions versus object database solutions (http://www.jpox.org/docs/polepos/results/html/index.html) and you'll see why it's in the big guys interest to focus on a solution that takes away a software team's 'freedom' to choose such a data storage mechanism.

    Even if you never go down the path of an OODBMS the big guys like to favour Hibernate because even though it supports multiple RDBMS vendors you will likely, very early, in the project start making RDBMS dependent decisions in your code and queries which provide a "RDBMS lock-in" mechanism for your project - nice and handy for them, not you! JDO's approach to queries is a Java like query language which gets rendered into the specific SQL flavour and semantics of a given RDBMS by the JDO implementation - not by you! (ie., the same reason people wrote C code in the 80's instead of assembler!)

    Just remember the *real* reason people like to promote FUD about JDO 2.0 is that it's too powerful and allows too much freedom of choice and very little lock in. They can't argue that it's technically inferior and that's why all the arguments against it contain more fluff than facts.

    BTW JDO2 is now also available in a number of free implementations including (but not limited to) www.jpox.org and Versant Open Access.
  258. All of them work fine[ Go to top ]

    I think that a lot of thought by a lot of great people has been put behind JDO, hibernate, EJB, jdbc. Just choose and use whichever you like. All of them work. If a DBA doesnt want you to have control over SQL, then dont use an ORM, use simple jdbc, write your own DAO. If a DBA doesnt have a problem, and you like one of the above, then go ahead and use them. Let the market choose it. If EJB3.0 spec is moving in the wrong direction ( like somebody in this thread claims) then it will have to correct itself to live longer. If i have a lot of options to choose from and i am confused, guess what, i will simply choose jdbc. If i have doubts on my sql skills, supplement the team with a good oracle/db2 person. After all it is teams which make software, one person doesnt need to be a know all.
    The market is flooded with solutions right now , some people like it and are excited about it, and some people feel over whelmed with it. I guess, both are right in their own ways. If more people feel overwhelmed, i guess things will start moving in a simpler direction, it could be EJB 3.0, JDO, SDO or JDBC. Its just a matter of perspective and experience with a particular technology.
  259. The View from the Bowl[ Go to top ]

    The view that matters is the market's rejection of JDO versus the widespread adoption of an EJB 3.0 style solution; to wit, Hibernate. You can make convincing arguments for complicated centralized government, but communism has proven itself to be a dismal failure. On paper there are all manner of benefitial aspects, but it's fatally flawed.

    Likewise, that steaming pile of practical ignorance they call the JDO specification is already washed up, if not dead in the water and bobbing close to shore. The sooner they send JDO specification spiraling down the vortex of the nearest porcelain bowl the better.
  260. The View from the Bowl[ Go to top ]

    The view that matters is the market's rejection of JDO versus the widespread adoption of an EJB 3.0 style solution; to wit, Hibernate. You can make convincing arguments for complicated centralized government, but communism has proven itself to be a dismal failure. On paper there are all manner of benefitial aspects, but it's fatally flawed. Likewise, that steaming pile of practical ignorance they call the JDO specification is already washed up, if not dead in the water and bobbing close to shore. The sooner they send JDO specification spiraling down the vortex of the nearest porcelain bowl the better.

    Well, this is all back to front. JDO 2.0 was passed as a spec a year ago because of demand from developers. Also JDO 2.0 is pretty close now to Hibernate and EJB 3.0/JPA in terms of features (although EJB 3.0 is still somewhat behind). So, if you call JDO 'steaming pile of practical ignorance', by implication you are implying the same about EJB 3.0.