Discussions

News: JDO 2.0 Public Review Reconsideration Ballot

  1. JDO 2.0 Public Review Reconsideration Ballot (144 messages)

    After a period of discussion between the JCP Executive Committee members and members of the JSR-243 Expert Group, JDO 2.0 has been submitted for reconsideration by the Executive. The reconsideration ballot closes on 28 February 2005.

    The resubmitted specification contains some clarifications regarding positioning and convergence issues. However no features were removed or deprecated.

    The JSR-243 page is http://www.jcp.org/en/jsr/detail?id=243


    Editors Note: On March 1st the JCP EC committee voted to approve JDO 2:
    http://www.theserverside.com/news/thread.tss?thread_id=32200

    Threaded Messages (144)

  2. from hibernate fan[ Go to top ]

    hi all
    actually iam a hibernate fan,and really i recommend hibernate to any one asking me for orm tool BUT i am strongly recommend and eager the ballot to vote for the jdo as it is really nice and mostly full spec and may b some day i use it
  3. JDO 2.0[ Go to top ]

    JDO 2.0 will rule (if only there would be an open source implementation with Hibernate's quality).

    Hope there will be at least one.
    Btw. I prefer JDO to Hibernate as it is based on a full (and feature full) spec as well as it is general persistance solution, not just ORM (although I would probably never be in position to use it for something other then ORM, it is a nice feeling that I could, and all that w/o performance hit in my ORM usage).
  4. When not ORM?[ Go to top ]

    ...it is general persistance solution, not just ORM (although I would probably never be in position to use it for something other then ORM, it is a nice feeling that I could, and all that w/o performance hit in my ORM usage).

    I respect JDO's abstraction from the persistence strategy (object vs. relational db), however all serious applications I have written have been backed by a relational database. Who here has written a medium to large scale app for a company when that company was not using a relational database? In my experience companies dictate this, which requires developers of object-oriented languages (like Java), to do ORM.

    Now, I still think JDO 2.0 should be approved. A lot of good apps and good developers are waiting for it so they can make use of the changes.

    But yes, I'll come clean. I'm a big Hibernate fan.
  5. Database abstraction[ Go to top ]

    ...I respect JDO's abstraction from the persistence strategy (object vs. relational db), however all serious applications I have written have been backed by a relational database. Who here has written a medium to large scale app for a company when that company was not using a relational database?

    Too bad you've never had the pleasure. Having worked on both storage systems, I wish everyone would get an opportunity to see the advantages.

    I have worked on several. The Versant database runs the American Stock Exchange trading systems ....32,000 tx/sec. Versant also runs the Sabre Systems airline reservations booking system used by most of the worlds airlines when you book a reservation. We also run the largest content management application in the world The Financial Times. I think the Versant databases are running at somewhere in the 14 Terra byte range though probably larger by now. Another good one is that Dow Jones, Reuters joint venture know as Factiva. We processed something like 280 Trillion dollars in institutional transactions just last year.

    Anyway, enough of a plug for the Versant database ;-) The abstraction is important for other reasons besides hooking up to object databases. It is also useful for LDAP, XML, Mainframe, etc. Also, JDO is as much about the storage layer as it is about the object lifecycle management that comes with the JDO / JSR220 approach when objects come into existence through the storage layer.

    The above being said, most application domain models are really not that complicated and for that and other reasons most people do and will continue to use relational databases. That's why we make a JDO driver with the best visual relational mapping capabilities on the market.

    Cheers,

    Robert Greene
    Versant Corporation
  6. now that's a big stick :-)[ Go to top ]

    We processed something like 280 Trillion dollars in institutional transactions just last year.

    ...a very big stick indeed! :-)

    -geoff
  7. ODBMS users[ Go to top ]

    ... not to mention every major telecom company like Ericsson, Lucent and Sprint.

    Every time you pick up the phone chances are the switch your call is rooted through runs a Versant database. The network management behind it certainly runs on a Versant database.


    The great idea behind JDO is that it gives customers a choice. Yes, you can run your whole application on Oracle if you so wish. If you get into serious performance problems and if you own the data model - try it on an object database. All that changes is a different properties file with a different URL - the code stays the same, it will just run 2 - 10 times faster.

    And this is one of the reasons why Oracle and IBM hate JDO and will try to bury it ...


    Cheers,

    Sven Erik Knop
    Versant Ltd
  8. Verant[ Go to top ]

    <snip snip>
    The Versant database runs ....32,000 tx/sec.
    <snip>I think the Versant databases are running at somewhere in the 14 Terra byte range though probably larger by now....
    <snip>We processed something like 280 Trillion ......

    Wow.
    Tpc.org says DB2 does 3 million TPC, independent and audited. Is there any performance papers or comparision for Versant DBs? I assume you still run a querry using something like this, so it should not be hard to test:
    http://www.versant.com/resources/faqs/faq_vsql.html

    Single digit milliseconds window for transactions?

    (I wonder how fast one can send transactions over; via mutiple 10gig ethernet cards to the db cluster. Some kind of a worker bee horizontal/vertical dispatcher to the db cluster is my guess. )

    It be nice to read some report/write up.

    .V
  9. Glad to see you're interested[ Go to top ]

    Nothing in the public domain on the AMEX system, but if you're really interested here is an IBM Redbook that talks about how we blow the doors off DB2. This one was verified by IBM's high volume website group in their Santa Teresa labs in the bay area.

    http://www.redbooks.ibm.com/redbooks.nsf/0/646bee868f80280185256b36005b577d?OpenDocument

    Happy reading.

    Robert Greene
    Versant Corporation
  10. Verant[ Go to top ]

    It looks like iBatis is data store agnostic too:
    "Versant/SQL is separate product to support industry standard SQL for Versant/ODBMS. The version of standard it support is SQL/92. It
    also supports ODBC and JDBC"
  11. Verant[ Go to top ]

    BTW, modern SQL versions are "object oriented" too:
    http://www.oracle.com/technology/products/database/application_development/pdf/SQL_2003_TWP.pdf
    SQL 2003 has standard syntax for stored procedures too, MySQL supports it too:
    http://dev.mysql.com/doc/mysql/en/stored-procedures.html
    JDOQL 2 standard doe's not exists. So how this stuff is more object oriented, more standard and more data store agnostic ?
  12. Verant[ Go to top ]

    BTW, modern SQL versions are "object oriented" too

    I think thats a marketing ploy. Fundemental impedance mismatch between relational model and OO-design, means OO languages and relational DB's will never be a perfect fit.

    Hitting the relational wall
  13. Verant[ Go to top ]

    BTW, modern SQL versions are "object oriented" too
    I think thats a marketing ploy. Fundemental impedance mismatch between relational model and OO-design, means OO languages and relational DB's will never be a perfect fit.Hitting the relational wall
    Yes, this stuff is a marketing, but "Fundemental impedance mismatch between relational model and OO-design" is a BS.
  14. Verant[ Go to top ]

    BTW, modern SQL versions are "object oriented" too:
    http://www.oracle.com/technology/products/database/application_development/pdf/SQL_2003_TWP.pdf
    SQL 2003 has standard syntax for stored procedures too, MySQL supports it too:
    http://dev.mysql.com/doc/mysql/en/stored-procedures.html

    Some modern SQL versions support this. The key thing to note is the word 'versions'. As usual with SQL, we have lots of versions, with different db vendors supporting different parts of the 'standard'. For example MySQL may have a standard syntax for stored procedures, but PostgreSQL doesn't. SQL Server doesn't. I would be surprised if you could show me any database that supports the all of core of SQL:1999, let alone SQL:2003.
    JDOQL 2 standard doe's not exists. So how this stuff is more object oriented, more standard and more data store agnostic ?

    JDOQL 2 as a JCP standard may not yet exist, but JDOQL 1 does, and I can use the same JDOQL on all the above databases I mentioned.
  15. Verant[ Go to top ]

    "The key thing to note is the word 'versions'"
    Yes, it is. There are many EJB and JAVA versions too.
  16. Verant[ Go to top ]

    Probably it a good reason to vote "no" for JDO2 too,there are many persistence standards and versions in JAVA.
  17. Verant[ Go to top ]

    Probably it a good reason to vote "no" for JDO2 too,there are many persistence standards and versions in JAVA

    And exactly how is this relevant to helping us cope with the problem of multiple and incomplete implementations of various SQL standards? These many persistence standards give the developer a choice as to how to deal with the problem of SQL versions.
  18. Verant[ Go to top ]

    This is a very big mistake form political point of view. You must claim JDO 2 integrates better with SQL than any existing API instead of blaiming SQL versions, drivers and relational model. The best way to prove this claim is to do it in specification and in implementations. It has practical value too, there is no problems to emulate SQL in the same way as JDOQL, Versant proved it by implementing JDBC driver for OODBMS.
  19. Verant[ Go to top ]

    'Flawed JDO Points the Way to the "Objectbase"'
     http://www.onjava.com/pub/a/onjava/2002/04/10/jdbc.html

    "I have two issues with JDO. The first is that somehow SQL has become a bad thing. SQL remains one of the major breakthroughs in our industry. Its non-procedural mechanics freed us from the high priests that used to control persisted data, and its power to bring together formerly unrelated populations of information still make it the most powerful computing tool of our time. The second is that JDO's abstraction treats a Database Management System (DBMS) like a file. Restated, instead of treating a database like an extension of memory for your application, you end up treating it like a file in a file system, where you open the file, read it into your application, write any changes back out to disk, and then close the file. This kind of behavior does not properly facilitate multi-user access."
    by Donald Bales, author of Java Programming with Oracle JDBC
  20. Verant[ Go to top ]

    " You do not need to learn and understand a different data-modeling language like SQL. You will discover that JDO is very easy to use."
    By David Jordan, Craig Russell
  21. Hi Juozas
    I have two issues with JDO ... you end up treating it like a file in a file system, where you open the file, read it into your application, write any changes back out to disk, and then close the file. This kind of behavior does not properly facilitate multi-user access.

    Anyone who has taken the time to glance at the JDO spec or read just about any introductory article on JDO will know that this is complete rubbish. JDO, Hibernate and Toplink all have a session concept (PersistenceManager in JDO) which among other things facilitates "multi-user access".

    Here is a rebuttal:

    http://www.onjava.com/pub/a/onjava/2002/05/29/jdo.html

    Cheers
    David
  22. Yes, author is not very familiar with JDO, he knows more about how "SQL is complex and incompatable with OOP".
  23. Versant[ Go to top ]

    Hi.

    I think we have two questions:

    1. Whether to use SQL directly from the Java code or not.

    and

    2. If we acutally use a Java-Class base DDL and query language on a POJO persistence solution; if the Java-based query should look like SQL (Hibernate) or like pure Java code (with Java syntax like JDO with <> != Collection-methods etc).

    To answer the first question:

    SQL is not a bad thing for those who want to use SQL DDL within your business logic directly on tables, rows and columns.

    However, business objects in Java don't have things like table, etc in it's language. What JDOQL does (and HQL in Hibernate I guess) is to define the queries based on the Java classes as DDL. The mapping to any store transforms these queries to be executed on the target store, which in many cases is a RDB which means transformation of a JDOQL query into SQL. Gut that SQL or whatever the store uses is not needed to be known by the programmer who writes the query. The SQL is actually generated in run time by the mapping tool.

    This means that if I do a refactoring of the tables by splitting them or splitting a column to two, I only have to change the mapping, not *any* Java code. The business logic (which I argue is both the Java code and the queries) is not changed due to this change in the SQL database. The mapping tool will however se to that the SQL code is changed with regard to the new RDB Scema (or new database product for that matter).

    For my part I would like to base the queries on the Java classes as DDL (like Hibernate and JDO).


    The second question is more of how you think as a programmer. Some programmers still think SQL'ish which is why they like Hibernates HQL, and some just want to use Java syntax in the Java code, which is why those like JDO's JDOQL

    For my part I like the Java like syntax in the Java DDL language.

    Cheers,
    Johan Strandler
    Smart Connexion
  24. Versant[ Go to top ]

    objects in Java don't have things like table, etc in it's language.
    SQL is a Set oriented langage, and that corresponds to Collections in Java. JSF uses RowSet as DTO and so does JDNC.

    I do not represesent UI in SQL, and I do not represent database in Java, what's the point if I now had that ability? Each has it's strengts. It be a strech to get a Swing Tabular Layout or DHTML made in SQL, but it could be done and it might have at least one plus. It has minuses too.
    What works best is seperation of concerns!

    For example ... lets bypass the graphic artist, becuase I know good enough what color to use and how rounded my buttons should be. It could be done!!!, no doubt. Or should we seperate concerns?
    Maybe some size or type of projects don't need a DBA. Else... the DBA has a role.

    .V
    (people, it gets hard to tell btwn boasting & personal opinion vs things that can be verified. Lets take a minute to try to back up a claim somehow/anyhow or even back up a personal opinion)
  25. Verant[ Go to top ]

    You must claim JDO 2 integrates better with SQL than any existing API instead of blaiming SQL versions, drivers and relational model.

    I simply don't understand this statement. All I am personally claiming is that JDO allows me to store, retrieve and manipulate persistent Java classes without having to worry about SQL versions, drivers, or relational models. That is all! There are other ways I could do this, such as by using Hibernate, but I prefer to use APIs which have multi-vendor support.
    It has practical value too, there is no problems to emulate SQL in the same way as JDOQL

    Yes, but which SQL? SQL92? SQL1999? SQL2003? SQL with Oracle extensions? SQL with SQL Server extensions?
    Versant proved it by implementing JDBC driver for OODBMS.

    Have you looked at the JDBC spec? Take a look at how many methods there are on DatabaseMetaData simply to deal with all the versions and incompatibilities of different SQL versions.

    No disrespect to Versant (I don't know of their JDBC driver), but implementing a JDBC driver does not mean you have also implemented a standard version of SQL. Look how little of SQL that MySQL implemented before version 4.1, yet they still provided a JDBC driver.
  26. Verant[ Go to top ]

    BTW, modern SQL versions are "object oriented" too:http://www.oracle.com/technology/products/database/application_development/pdf/SQL_2003_TWP.pdfSQL 2003 has standard syntax for stored procedures too, MySQL supports it too:http://dev.mysql.com/doc/mysql/en/stored-procedures.html
    Some modern SQL versions support this. The key thing to note is the word 'versions'.

    If you read JDBC 3 "version"
    http://java.sun.com/products/jdbc/download.html#corespec30
    it specifies in section 17.4.3 page 157 that it is compliant with ANSI 99 and supports table inheritence.

    If you have any ANSI 99 SQL books (I have 3, specific to ANSI 99 SQL - not counting my other SQL books) it specifies that ANSI 99 standard for doing portabl stroed procedures.

    JDO has vendor propritory extensions too. Only a % of applications use Java, and only a % of users use JDO.
    Most use SQL.

    .V
  27. Verant[ Go to top ]

    If you read JDBC 3 "version" http://java.sun.com/products/jdbc/download.html#corespec30it specifies in section 17.4.3 page 157 that it is compliant with ANSI 99 and supports table inheritence.
    I do not remember JDO specification, but in EJB 3 it is prhabited to use standard SQL or JDBC escapes, you must use native query.
  28. Verant[ Go to top ]

    JDO has vendor propritory extensions too.

    JDOQL doesn't. One of the reasons for JDO 2.0 is to standardise things that were vendor extensions in JDO 1.0.

    <blockquote?If you read JDBC 3 "version"
    http://java.sun.com/products/jdbc/download.html#corespec30
    it specifies in section 17.4.3 page 157 that it is compliant with ANSI 99 and supports table inheritence.
    This simply means that the driver allows that syntax in SQL, so you can use it if the underlying database supports it. Having a JDBC 3.0 driver for a database does not mean that the database supports table inheritance.

    The spec says that the intent of the JDBC 3.0 API is to provide access to the subset of SQL99 features likely to be supported in the future. Please note that the spec specifically includes the word 'subset'! Also, it only 'provides access'. It does not require that those features are present - this is why DatabaseMetaData has so many 'is this feature present?' testing methods.
    If you have any ANSI 99 SQL books (I have 3, specific to ANSI 99 SQL - not counting my other SQL books) it specifies that ANSI 99 standard for doing portabl stroed procedures.

    You can have all the 'SQL standard' books you like, but that has no bearing on how much or little of that standard a particular database provides. You list all the standards you like, but that won't help me write portable stored procedures on PostgreSQL or SQL Server.
    Only a % of applications use Java, and only a % of users use JDO. Most use SQL.

    This is irrelevant. Just because some applications use SQL directly is no reason for all applications to do this. I guess you want to drop Java as well then?
  29. Verant[ Go to top ]

    Only a % of applications use Java, and only a % of *Java* users use JDO. Most use SQL.

    This is irrelevant.

    We are then back to claiming:
    -a trilion trsanctions ...
    -25 millecond response ...
    -and 9000 times faster....

    That would be more relevent I guess for JDO and Preveyer, et al.

    .V
  30. Verant[ Go to top ]

    You can have all the 'SQL standard' books you like, but that has no bearing on how much or little of that standard a particular database provides. You list all the standards you like, but that won't help me write portable stored procedures on PostgreSQL or SQL Server.
    Do you advokate workarounds and adapters or ORM ? It must be very trivial to implement adapter for SQL if you can to it with JDOQL. http://jsqlparser.sourceforge.net this is a good tool to start or you can generate parser yourself.
  31. Verant[ Go to top ]

    You can have all the 'SQL standard' books you like, but that has no bearing on how much or little of that standard a particular database provides. You list all the standards you like, but that won't help me write portable stored procedures on PostgreSQL or SQL Server.
    Do you advokate workarounds and adapters or ORM ? It must be very trivial to implement adapter for SQL if you can to it with JDOQL. http://jsqlparser.sourceforge.net this is a good tool to start or you can generate parser yourself.

    I rarely used stored procedures. I have almost all my logic in pure Java. I was using stored procedures as an example of incompatibility between databases.
  32. SQL parsing[ Go to top ]

    I know I'll regret this:
    this is a good tool to start or you can generate parser yourself.

    I'm sure it is and I'm sure we can, but most of us get paid to write applications, you know.
  33. SQL parsing[ Go to top ]

    I know I'll regret this:
    this is a good tool to start or you can generate parser yourself.
    I'm sure it is and I'm sure we can, but most of us get paid to write applications, you know.
     Yes, but we pay for JDO.
  34. SQL parsing[ Go to top ]

    I know I'll regret this:
    this is a good tool to start or you can generate parser yourself.
    I'm sure it is and I'm sure we can, but most of us get paid to write applications, you know.
    &nbsp;Yes, but we pay for JDO.

    You don't have to: www.jpox.org
  35. promises promises[ Go to top ]

    I know I'll regret this:
    this is a good tool to start or you can generate parser yourself.
    I'm sure it is and I'm sure we can, but most of us get paid to write applications, you know.
    &amp;nbsp;Yes, but we pay for JDO.
    You don't have to: www.jpox.org

    from jpox: JPOX currently supports persisting of data to a large selection of Relational Database Management Systems (RDBMS). It is planned to extend this in the future to support various file-based storage mechanisms, as well as OLAP databases.

    Yet Another Proof that:
    - JDO is ORM;( maybe a good one)
    - supporting other storages is difficult at best and smells like gimmick to get piece of ORM/RDBMS market pie;

    Please please please do not force square peg into round hole:
    - leave flat files flat: they have excellent API that has its niche;
    - leave LDAP storages alone, they too have nice API and their niche;
  36. promises promises[ Go to top ]

    Hi Konstantin
    Yet Another Proof that:- JDO is ORM;( maybe a good one)- supporting other storages is difficult at best and smells like gimmick to get piece of ORM/RDBMS market

    Versant Open Access will be the primary Java interface to Versant ODBMS from version 7 of the database. In other words the most efficient way to use Versant ODBMS will be to use the JDO API. No gimmick! Thats much better for Versant customers than using a proprietary API. And its good for Versant as people using JDO against relational databases will be able to try Versant ODBMS with little effort.

    We are also implementing EJB 3 persistence.

    Cheers
    David
  37. promises promises[ Go to top ]

    Versant Open Access will be the primary Java interface to Versant ODBMS from version 7 of the database. In other words the most efficient way to use Versant ODBMS will be to use the JDO API.

    It is quite possible that Versant ODBMS will work well with JDO API. I would guess that Hibernate might expose JDO API too. All those Object persistence APIs are so similar: JDO, ODMG, Hibernate, Castor.
    But JDO spec is not API alone.

    And as I said many times: JDO is fine with me if it will drop claim to support just about everything, I have no doubts that JDO fits well into RDBMS, might work well with ODBMS – as you just said there is separate thing: Versant ODBMS, which is not part of JDO.
    But I saw no reasons yet which would indicate that JDO could work well with flat and hierarchical storages.

    As Patric (Kodo) said: We've actually thought about shipping an in-memory version of Kodo, but have always decided not to because of the existence of things like HypersonicDB and Derby.
    Very good – lets not reinvent the wheel, and not to encourage wheel reinventions.

    David, you actually gave only solid reason IMO why JDO might be beneficial: as migration/trial path from RDBMS to ODBMS.
    Could you tell in which features in JDO you want to see for better ODBMS support?
    What extension over core JDO 2 Versant provides?
  38. promises promises[ Go to top ]

    JPOX currently supports persisting of data to a large selection of Relational Database Management Systems (RDBMS). It is planned to extend this in the future to support various file-based storage mechanisms, as well as OLAP databases.Yet Another Proof that:- JDO is ORM;( maybe a good one)- supporting other storages is difficult at best and smells like gimmick to get piece of ORM/RDBMS market pie;Please please please do not force square peg into round hole:- leave flat files flat: they have excellent API that has its niche; - leave LDAP storages alone, they too have nice API and their niche;

    FYI: JDORI already support flat files, so this is just a matter of integration with the existing JPOX codebase. The rationale in providing flat files in JPOX is to continue supporting users that are using flat files datastores from the JDORI. This is going to be done by Apache anyway, so the rationale does not apply today.

    I have started the JDO with OLAP datastore support but using MDX queries and not JDOQL. We will certainly not support all JDO operations in the first phases of the project and some of them will not apply to OLAP.

    I think JDOQL has its place but I also agree that SQL and other query languages have its place when applied to their respective datastores. SQL and OQL are my baselines when choosing query languages. This battle of JDOQL vs SQL is nosense and design choices are sometimes difficult to be accepted and can't be imposed.
  39. promises promises[ Go to top ]

    I think JDOQL has its place but I also agree that SQL and other query languages have its place when applied to their respective datastores...This battle of JDOQL vs SQL is nosense and design choices are sometimes difficult to be accepted and can't be imposed.
    And I might add, Erik, this is exactly why the JDO specification is explicitly designed to support query languages in addition to JDOQL. JDO 2.0 standardizes the use of SQL queries for the JDO/R implementations, and I see no reason why most JDO implementations couldn't support EJBQL or even HQL.

    --matthew
  40. promises promises[ Go to top ]

    And I might add, Erik, this is exactly why the JDO specification is explicitly designed to support query languages in addition to JDOQL. JDO 2.0 standardizes the use of SQL queries for the JDO/R implementations, and I see no reason why most JDO implementations couldn't support EJBQL or even HQL.--matthew
    Ooops. Now we have whole bunch of supported languages.
    Wait a minute I saw that before: remember that dreaded JDBC? It provides API but you have to send ‘proprietary’ SQL to the database, weird!
    :)
  41. promises promises[ Go to top ]

    "JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level.", but as I understand JDO implementation must call "java.sql.Connection.nativeSQL(java.lang.String)"
    This method "Converts the given SQL statement into the system's native SQL grammar.
  42. use it before commenting[ Go to top ]

    I have the strange feeling that a lot of people have not even tried to use JDO before commenting. Konstantin just dont get the fact that a lot of JDO implementations also support different datastores like XML or flatfiles and that this can be handy at times.

    Nobody says that you have to use this datastore, but what speaks against using the same API (JDO) to also map XML files to java objects? And i dont think that JDOs success is only because of the claim that its datastore neutral. Its success is that its the most portable persistence API today, of course there are a lot of vendor extensions in 1.0 and there will be some in 2.0, but tell me any other standard that is more portable (dont mention EJB2.x here ;-))

    So here is my personal bottomline:

    1. ORM is not sacrificed in JDO because of other datastores that are supported.

    2. JDO allready proved that its datastore neutral, just because JPOX has decided to put in the mainstream features first is not a counter argument.

    3. Go to solarmetric.com or any other JDO vendor and get yourself a trial version and code some stuff instead of cut&pasting JDO spec phrases.

    Thanks to Eric and Abe to put in some technical backed stuff in here. And for the parsergenerator guys in this thread, i get paid for developing and designing applications, not for reinventing the ORM wheel.

    Marc
    http://www.logemann.org
  43. use it before commenting[ Go to top ]

    "ORM is not sacrificed in JDO because of other datastores that are supported".
    Probably it is the right point. If this is true then I need new specification. EJB3 is similar to JDO and one of them can die, JDBC is a connectivity API and it is too low level for applications development.
    As I undrstand many people work with RDBMS and need support industry standards like SQL, high level data access framework is very usefull for application development.
     So probably we (JDO "enemies") need to submit iBatis as a standard and to forget JDO stuff.
  44. use it before commenting[ Go to top ]

    BTW Remove my name from your petition please, I was wrong and you proved it. Both specifications support SQL in the same way and I see JDO is not going to improve it. Probably EJB3 will support it better or iBatis will be aproved as standard if impedence mismach is unsolvable.
  45. promises promises[ Go to top ]

    <blockquotePlease please please do not force square peg into round hole:- leave flat files flat: they have excellent API that has its niche; - leave LDAP storages alone, they too have nice API and their niche;
    Konstantin

    I honestly do not believe that anyone is trying to force square pegs into round holes here. Nobody suggests that JDO should be the default access mechanism for flat files or LDAP servers. Indeed, there are generic APIs for this, and nobody is trying to replace them.

    However, there are people who want to store object graphs not only in the R-or-OO DBMS, but also, say, in the file system or a LDAP server. These people want to use the same API they use for persisting object graphs in other types of datastores. They will (usually) not expect the same runtime characteristics (eg performance) from diffent underlying datastores.

    People may have many reasons for wanting to do this. Some that come to my mind are: speed of execution (in-memory store for automated tests), simplicity of installation (file system store for rich client app with offline capabilities), ...

    I am really trying to see your point, i.e. how any of this could possibly cause a problem or grievance to you.

    Regards,
    Oliver
  46. Versions versions[ Go to top ]

    ...You can have all the 'SQL standard' books you like,
    and use them as fuel! JDO spec PDF is a real deal!:)
    but that has no bearing on how much or little of that standard a particular database provides. You list all the standards you like, but that won't help me write portable stored procedures on PostgreSQL or SQL Server...

    How JDO might help portability of stored procedures?

    -----
    From the thread above it is pretty clear:
    1. JDO implementations have to implement JDOQL on flat/hierarchical storages to claim JDO compatibility;
    2. Because file does not support relational algebra – those implementations must implement relational algebra themselves;
    3. Efficient implementation of relational algebra is nothing else than RDBMS ( many megs of download and runtime). After all RDBMS do exactly that: implement relational algebra atop of flat files;

    Conclusion: all possible JDO implementations on flat files:
    - are huge as any RDBMS;
    - or simplistic and inefficient;
    In both cases I do not see need for them.
  47. Versions versions[ Go to top ]

    How JDO might help portability of stored procedures?

    It can't. But JDO/JDOQL allows most business logic to be expressed in a database-vendor-neutral fashion. That works for me.
    1. JDO implementations have to implement JDOQL on flat/hierarchical storages to claim JDO compatibility;

    No. This statement is wrong. I think you are seriously misunderstanding this situation, and it might explain why you have such an objection to JDO.

    Not all JDO implementations have to implement JDOQL on flat/hierarchical stores. This only applies to JDO implementations that claim to support these stores.

    It is even perfectly acceptable for a particular JDO implementation to only implement JDOQL for a single vendor's database, providing that implementation of JDOQL passes the compatibility tests for JDOQL and JDO.
    2. Because file does not support relational algebra – those implementations must implement relational algebra themselves;

    Yes.
    3. Efficient implementation of relational algebra is nothing else than RDBMS ( many megs of download and runtime). After all RDBMS do exactly that: implement relational algebra atop of flat files;

    Actually, they don't. Some work on raw file systems, and some even work in RAM, but that is of no consequence.
    Conclusion: all possible JDO implementations on flat files:
    - are huge as any RDBMS;

    No, because JDOQL does not provide all the functionality of a typical RDBMS. That is not what JDOQL is for.
    - or simplistic and inefficient;

    You just claimed that RDBMSes were implemented on flat files. Why should any other system that works on flat files be simplistic and inefficient?
    In both cases I do not see need for them.

    Fine. Don't use them then. What is the problem?
  48. Versions versions[ Go to top ]

    Not all JDO implementations have to implement JDOQL on flat/hierarchical stores. This only applies to JDO implementations that claim to support these stores.
    So, they are not storage agnostic after all.
    Fine. Don't use them then. What is the problem?

    Yeah, that is _really_ hard to understand:

    I do not like garbage being dumped on my neighbor’s backyard, even that is out of sight.

    You act like that neighbor (or truck driver) they both have hard time understanding my motives – that is not my backyard, what is the problem?
  49. Versions versions[ Go to top ]

    Not all JDO implementations have to implement JDOQL on flat/hierarchical stores. This only applies to JDO implementations that claim to support these stores.
    So, they are not storage agnostic after all.

    JDO is a datastore agnostic specification. This means that a developers code need not know about the nature of the storage mechanism. This frees up JDO implementors to provide a variety of storage solutions. This is great for the developer - no matter what the storage, they are guaranteed to have full JDOQL support, and the JDO API.

    This is why having JDO as a specification and not just a single product is so important. Having many vendors and groups providing JDO means that effort can be put into provide support for a wide range of stores and databases.
    I do not like garbage being dumped on my neighbor’s backyard, even that is out of sight.

    You act like that neighbor (or truck driver) they both have hard time understanding my motives – that is not my backyard, what is the problem?

    Well, I'm sure JDO vendors that support flat files will be overjoyed to hear you label their work as 'garbage'.

    I still can't see why this bothers you - if you think it's so bad, don't use it.

    But, I have spent too much time on this, interesting though it is..... I'm sure others will counteract your FUD if they feel it necessary.

    Before I stop, I would like to say I have been impressed by the attitude of JDO Vendors in this thread (and others). They are willing to mention the qualities of competitors in order to promote JDO 2.0, and they have remained calm and informative in the face of considerable FUD. This is one of the reasons I am a fan of JDO.
  50. Versions versions[ Go to top ]

    Fine. Don't use them then. What is the problem?
    Yeah, that is _really_ hard to understand:I do not like garbage being dumped on my neighbor’s backyard, even that is out of sight.You act like that neighbor (or truck driver) they both have hard time understanding my motives – that is not my backyard, what is the problem?
    Konstantin, are we to understand that your point is that just because you don't need/want/like JDO, noone else should be able to use it? Are you sure this is reasonable?

    Regards,
    Henrique Steckelberg
  51. me![ Go to top ]

    Who here has written a medium to large scale app for a company when that company was not using a relational database?

    Me.

    In the fields of bioinformatics with huge volumes and highly complex structured combined with stunning object counts.

    We used VERSANT those days and created our own. I'd wich more companies did it with OODB bc. ORM *is* on additional step that should be avoided at all cost.

    From the project I currently have to work on that even with Hibernate it is still just a nightmare. What I want to do is to persist. What I need to do is to map,declare,think,compile,generate,enhance,... . Thats bad.
  52. me![ Go to top ]

    What I want to do is to persist. What I need to do is to map,declare,think,compile,generate,enhance,... . Thats bad.

    http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutput.html
  53. When not ORM?[ Go to top ]

    Who here has written a medium to large scale app for a company when that company was not using a relational database?

    I have. Look at http://smartconnexion.se/casestudy_gemstone_swedbank.pdf

    Worked excellent and war extremely productive for business logic, but had to be shifted to a mainframe solution a few years later because the product died and there was no standard API for OODB's. Thats why I don't dare to bet on proprietary products like Hibernate, Toplink or Cocobase. Burned once...

    However, Both Gemstone and Versant did recognise this problem, and began (with al lot of other very experienced people) writing on a Java Standard called JDO. I guess that's why JDO 1 didn't have to much definitions of ORM. But with an almost no changed JDO 1 we now soon will have JDO 2, that in fact is the worlds first and ORM standard! :-)

    Cheers,
    Johan Strandler
    Smart Connexion
  54. JDO 2.0[ Go to top ]

    JDO 2.0 will rule (if only there would be an open source implementation with Hibernate's quality).Hope there will be at least one.

    Apache has launched a JDO project

    Check this out:

    http://theserverside.com/news/thread.tss?thread_id=30443

    With regard to the upcoming vote, I'm afraid no amount of repositioning will help with the vote. It appears that the (J2EE) vendors that voted against the JDO 2.0 specification did not do so due to technical merits or positioning. It was a political vote.

    I presume/assume/hope that the pro-JDO members of the JSR are playing politics having realized the hard way with the previous vote that there's more to a success that technical merit and hard work.


    PJ Murray
     CodeFutures Software

    Disclosure of interest: CodeFutures Software ships a data persistence code generator that support JDO 1.0 (along with EJB CMP and JDBC DAOs) and has promised its customers to support JDO 2.0.
  55. JDO 2.0[ Go to top ]

    JDO 2.0 will rule (if only there would be an open source implementation with Hibernate's quality).

    You can try: http://www.jpox.org. In the appropriate time we will collect and report its quality metrics.
  56. JDO 2.0[ Go to top ]

    I prefer JDO to Hibernate as it is based on a full (and feature full) spec as well as it is general persistance solution, not just ORM (although I would probably never be in position to use it for something other then ORM, it is a nice feeling that I could, and all that w/o performance hit in my ORM usage).

    One size does NOT fit all. That is exactly why JDO should not be approved till it has a nonsensical claim of storage independence.
  57. JDO 2.0[ Go to top ]

    One size does NOT fit all. That is exactly why JDO should not be approved till it has a nonsensical claim of storage independence.

    huh? One size does not fit all implies that you want choice. But limiting the types of persistent stores I can talk to limits choice.

    If you don't like that feature of JDO, don't use that feature. what's the problem??

    btw - SDO adopts a similar persistence-store-agnostic architecture too (though it's XML flavoured). Do you hate SDO too? :-)
  58. JDO 2.0[ Go to top ]

    One size does NOT fit all. That is exactly why JDO should not be approved till it has a nonsensical claim of storage independence.
    huh? One size does not fit all implies that you want choice. But limiting the types of persistent stores I can talk to limits choice.

    In which way do I limit choice?
    I do not prohibit anybody from using suitable kind of storage, quite contrary. One API/Query language does not fit all types of storages and one API promotes:
    - false promise to work well on storages which do not support certain ORM operations;
    - underuse of particular storage strengths;
    Or it becomes lowest common denominator that does not work well at all for anything more complex than “Impress Executive Officers Presentation”
  59. JDO 2.0[ Go to top ]

    In which way do I limit choice? I do not prohibit anybody from using suitable kind of storage, quite contrary. One API/Query language does not fit all types of storages and one API promotes:
    - false promise to work well on storages which do not support certain ORM operations

    What are "ORM operations" and why do they apply to anything but relational "storages"? All JDO operations are fully supported in various implementations that layer on top of RDBs, ODBs, XML, etc. These products fully support the spec and meet their customers needs. How can you say you're not trying to limit choice when you're trying to take JDO away from these happy users?
    ;- underuse of particular storage strengths

    You have said this in a few other threads I can think of, and you've yet to provide a single example of "underuse", despite repeated requests for one. Either give an example of how JDO "under-uses" the data store compared to competing solutions, or please stop making claims you can't back up.
    ;Or it becomes lowest common denominator that does not work well at all for anything more complex than “Impress Executive Officers Presentation”

    Again, give an example of what features JDO is lacking compared to competing solutions on a particular store, or stop making these claims. You repeat the same thing on every thread, and have yet to provide a shred of backing evidence. It's getting a bit silly.
  60. JDO 2.0[ Go to top ]

    It is no sillier than JDO claim of storage agnosticism. Please point at couple of JDO implementations that use LDAP or csv files and provide full range of ORM operations and full SQL like query semantic: JOINs HAVING GROUP BY etc?

    JDO is simply an attempt to standardize ORM – that is fine with me, make sense. Attempt to cover everything –does not.
  61. JDO 2.0[ Go to top ]

    JDO is simply an attempt to standardize ORM

    Wrong. JDO is an attempt to standardize POJO persistence.

    JDO 2.0 includes an attempt to standarize how JDO uses ORM when it is persisting to a relational store.
  62. JDO 2.0[ Go to top ]

    Please point at couple of JDO implementations that use LDAP or csv files and provide full range of ORM operations and full SQL like query semantic: JOINs HAVING GROUP BY etc?

    ORM = Object/Relational Mapping. It is nonsensical to talk about ORM operations on top of XML or ODBs or LDAP or CSV. I tried to hint at this in my earlier response to you. Taking the time to learn a little more about object persistence and its associated terminology might help you express your ideas more effectively.

    You wanted some links to non-relational implementations, so...

    ODB implementation:
    http://www.versant.com/products/fastobjects

    XML, RDB, ODB implementation:
    http://www.xcalia.com/home.jsp

    And as I've told you before on other threads, Kodo JDO has had an ODB implementation, ships with a sample XML implementation, and has done legacy data store implementations for clients, in addition to our primary RDB implementation used by TSS and others. We could do LDAP and CSV fairly easily if someone contracted us to do so. In fact, a user could even code his own LDAP or CSV back-end; we document the hooks necessary and provide the source code to our sample XML back end as an example.

    All these implementations support the full JDO 1 spec, and some like Kodo support most of JDO 2 already. They'll all support JDO 2 soon after it's finalized.

    There are many, many more JDO implementations, but those are some big ones that do non-relational stores that I knew off the top of my head.
  63. JDO 2.0[ Go to top ]

    ORM = Object/Relational Mapping. It is nonsensical to talk about ORM operations on top of XML or ODBs or LDAP or CSV.
    Glad you acknowledge this. This is exactly my point.
    Now, lets read spec JDO2 #14.3 : [spec] JDOQL keywords are the following:
    select, SELECT, unique, UNIQUE, distinct, DISTINCT, avg, AVG, min, MIN, max, MAX,
    count, COUNT, sum, SUM, as, AS, imports, IMPORTS, into, INTO, from, FROM, exclude,
    EXCLUDE, subclasses, SUBCLASSES, where, WHERE, order, ORDER, by, BY, ascending,
    ASCENDING, asc, ASC, descending, DESCENDING, desc, DESC, group, GROUP, having,
    HAVING, imports, IMPORTS, parameters, PARAMETERS, variables, VARIABLES,
    range, RANGE, to, TO. [/spec]

    Are you suggesting that GROUP, HAVING etc. do nothing but throw exceptions?

    All these implementations support the full JDO 1 spec
    JDO1 is the vendor trap, in my experience it was not possible to do anything useful without vendor extensions. Looks like JDO 2 is designed in the same way.

    XML, RDB, ODB implementation: http://www.xcalia.com/home.jsp
    No words on what exactly they have implemented atop of XML storage. That makes me nervous because dear vendors have nasty habit of putting fine print somewhere that will say: *implement subset of spec – work is in the progress, if you need more information please contact our sales department. They kind of say it: Xcalia is currently working on supporting new data sources. If you are interested in building a new specific LiDO Storage Manager in could be done through a Lab-to-Lab partnership.


    OK. You got me – there is JDO implementation atop of XML…
    I have more questions:
    - is it proprietary XML, that would make it rough equivalent to the brilliant XMLforImages format proposal: <point x=1 y=2 r=255 g=0 b=0/> etc.
    - or it can map to a user defined XML format?

    I guess in both cases JDO implementation have to implement relational algebra (less in JDO1 and more in JDO2). Well DB vendors spent decades perfecting their relational engines and underlying file and even device formats. Why should I trust JDO doing that right and in scalable? Still something does not click.

    I agree, we can do it (JDO2 atop flat something) , still convinced that we should NOT do it.
  64. Da - there's no reason to that logic. I'm with ya man! I been Skiing for years and there's just no way I'm trying that snowboard now.

    Rock steady dude.
    -Robert
  65. JDO 2.0[ Go to top ]

    Hi Konstantin
    ORM = Object/Relational Mapping. It is nonsensical to talk about ORM operations on top of XML or ODBs or LDAP or CSV.
    Glad you acknowledge this. This is exactly my point.Now, lets read spec JDO2 #14.3 : [spec] JDOQL keywords are the following:select, SELECT, unique, UNIQUE, distinct, DISTINCT, ... group, GROUP, having,HAVING, imports, IMPORTS, parameters, PARAMETERS, variables, VARIABLES,range, RANGE, to, TO. [/spec]Are you suggesting that GROUP, HAVING etc. do nothing but throw exceptions?

    JDOQL is designed so that all of it can be translated into SQL. This is in recognition of the importance of relational databases. If the underlying store does not have the full query capabilities of a relational database then the implementation may have to implement parts of JDOQL itself. If the underlying store is just a flat file on the filesystem then the implementation will have to implement JDOQL directly on top of that.

    If you need high performance query capability then probably you should use JDO on a relational database. If your model is complex and you do a lot of navigation then JDO on a high performance object database like Versant might be the best choice. If you are writing a small embedded app then JDO on a flat file might be the best choice.

    The point is that JDO supports all of the above options without sacrificing relational database capability.

    Cheers
    David
    Versant Open Access
  66. JDO 2.0[ Go to top ]

    David,

    It's clear, that you (Versant and others) should provide to us (community) much more info about HOW you implement JDOQL on top of flat files, LDAP, XML, ACN.1 etc. Don't hesitate write huge article and post in here. We will read. But, because now we havn't this information, and have no idea how to do that, we not trust you can do that good. JDO vendors should do much more to show us how this can work. This exactly what Oracle/Sybase/IBM do. They permanently prove it work.
  67. JDO 2.0[ Go to top ]

    Hi Dimitriy
    David,It's clear, that you (Versant and others) should provide to us (community) much more info about HOW you implement JDOQL on top of flat files...

    Versant Open Access currently supports 14 different relational databases (using JDBC) and Versant Object Database (using a Versant specific protocol). For JDBC we translate JDOQL into an SQL query string. For Versant ODBMS we translate JDOQL into a Versant specific query tree.

    Maybe some of the JDO vendors supporting flat files and XML stores could continue this thread.

    Cheers
    David
  68. JDO 2.0[ Go to top ]

    David,
    ...For Versant ODBMS we translate JDOQL into a Versant specific query tree.

    Believe you or not, quote above is very interesting for us to read about. How you do that? Convert to AST tree? or to String? Do all features of Versant OSQL can be used via JDOQL?

    1: Go to write article immediatly! :)
    Maybe some of the JDO vendors supporting flat files and XML stores could continue this thread

    They are allready goto 1: :)
  69. JDO 2.0[ Go to top ]

    David,It's clear, that you (Versant and others) should provide to us (community) much more info about HOW you implement JDOQL on top of flat files, LDAP, XML, ACN.1 etc. Don't hesitate write huge article and post in here. We will read. But, because now we havn't this information, and have no idea how to do that, we not trust you can do that good. JDO vendors should do much more to show us how this can work. This exactly what Oracle/Sybase/IBM do. They permanently prove it work.

    This actually seems like a very good idea!

    I got the perception that many people think that JDOQL must have some SQL code behind the scenes, which is far from the truth. One can think so, because JDOQL 2.0 have SQL like expressions which are well mapped to SQL in the end, hence helping out an ORM implementation al lot.

    So, an educational "pamflett"/paper that scetches out how different JDO implementations, with different stores could be architected, could be a huge step fordward in the education about the difference of POJO persistence - ORM (as a subset of POJO persistence) - and finally relational DB's and SQL.

    Another implementation of JDO that I really miss is a plain RAM based implementation of JDO PersistentManager. Preferably I would like to see such implementation in an open source project.

    This RAM-only based JDO implementation would be wounderful to use in large JUnit test suits, since it would be both transactional and have the JDOQL. Not useful for real persistence though since everything vanishes when the process dies, but as for JUnit tests and to be used as a simple example of a non-SQL relational-db-ORM implementation of JDO.

    I think I dont't have enough time to do such a Open Source project by myself. Anyone up for it?

    Cheers,
    Johan Strandler
    Smart Connexion
  70. In-memory JDO[ Go to top ]

    Another implementation of JDO that I really miss is a plain RAM based implementation of JDO PersistentManager.

    Johan,

    We've actually thought about shipping an in-memory version of Kodo, but have always decided not to because of the existence of things like HypersonicDB and Derby (in-memory RDBs). Internally, we use in-memory relational databases for unit testing quite a lot, with great success.

    -Patrick

    --
    Patrick Linskey
    Kodo JDO
    SolarMetric Inc.
  71. In-memory JDO[ Go to top ]

    Another implementation of JDO that I really miss is a plain RAM based implementation of JDO PersistentManager.
    Johan,We've actually thought about shipping an in-memory version of Kodo, but have always decided not to because of the existence of things like HypersonicDB and Derby (in-memory RDBs). Internally, we use in-memory relational databases for unit testing quite a lot, with great success.-Patrick--Patrick LinskeyKodo JDOSolarMetric Inc.

    Well, yes. I have tried HSQL and it works excellent! I think I just got a bit carried away in trying to illustrate non-RDB solutions. :-)

    Still, thanks for the tip.

    Johan Strandler
  72. Full Power of JDOQL is Porttable[ Go to top ]

    Every JDO-compliant implementation must support JDOQL. JDOQL itself has no optional components and must be supported in full.

    Thus if a vendor provides a JDO implementation for a certain backend store, and they claim that implementation to be JDO-compliant, then they must fully support JDOQL against that backend. Indeed, to brand as JDO-compliant they must pass the TCK tests!

    So yes, JDOQL is portable and the full power of JDOQL is available ragardless of the datastore paradigm.
  73. Full Power of JDOQL is Porttable[ Go to top ]

    Every JDO-compliant implementation must support JDOQL. JDOQL itself has no optional components and must be supported in full.
    It is fine, if you will do the same with SQL then it will be the best data access framework for JAVA.
  74. Hello Konstantin and others

    First of all, I'd like to thank Abe & David for having mentionned a competitive product like LiDO.
    Second, sorry for that long post.

    I'm the CTO of Xcalia, and we provide a Data Access technology which gives access to different kind of data sources. Today, LiDO can access RDBMS, ODBMS, XML files and FileDB (a 100% Java fast and light storage for embedded systems).

    I've quite often read on TSS posts from Konstantin about the uselessness of DB-agnostic APIs. I decided not to enter into any kind of debate with him because I think it is almost impossible to convince him.
    I must admit he is very "persistent" in his approach.

    So, I don't want to start that debate with him today, just answer his questions/concerns about LiDO XML. Before that I'd like to say I'm working with object technologies since the 80's, and I'm working with RDBMS since the same time. I've also used a lot of non-RDBMS in my career, like hierarchical databases, network databases, object databases, C-ISAM, TP monitors and much more exotic data sources on mainframes. BTW: many young Java developers tend to think that everything "important" is stored in RDBMS, they forget the mainframe market that is still huge and growing. I think I have a reasonable knowledge of internals of DBMS engines, TP monitors and so on (some people know I used to work for a DBMS vendor in the past).

    LiDO XLM is a true O/XML mapping layer. It means it is not just yet another Java XML binding, it is a real mapping layer between any XML grammar and any Java model. We provide the same kind of benefits on top of XML files that we provide with O/R mapping on top of RDBMS: we reduce the gap between XML models and Java models. So the idea is not to be able to store some Java objects into an XML file with a fixed XSD, but rather to be able to map any Java models to any XML grammar. LiDO XML does support the full JDO API. Anything we support on RDBMS, we support it too on XML, including transactions, JDOQL and so on. Obviously, you cannot expect the same performance from queries on a big XML file than you expect from a true database engine, but who would expect this ?

    LiDO XML is available since 2 years as a supported product. This is not a prototype. You can download it and play with it, we deliver several examples. We have many users using it and they perfectly understand its benefits. The goal is not to replace RDBMS by XML files. But sometimes it is convenient to store some objects into XML files. And it is very convenient to use the same APIs, the same concepts, the same query language, the same product to transparently manipulate both XML and RDBMS data sources from Java applications.

    A frequent objection against products being able to map multiple data sources (universal mapping) is that they COULD NOT BE OPTIMIZED for each supported data source. There is no scientific argument to sustain that plea. It is just a question of implementation and software design. I know a lot of pure O/R mapping tools that are much less efficient than LiDO to access RDBMS. LiDO comes with all the ORM opitmizations that are found in best O/R mapping products.

    Once again Konstantin, I respect your opinion, and I don't even try to convince you , but I can't let you publicly say things that are inaccurate or at least incomplete. See no aggressive words in my post, I'm cool.

    Hope this could help readers to make their own opinion.
    Nothing could replace your own validation.
    Many things are said these days about Data Access and standards. Most of them are far from what users really need.

    Best regards, Eric.
  75. JDO 2.0[ Go to top ]

    ORM = Object/Relational Mapping. It is nonsensical to talk about ORM operations on top of XML or ODBs or LDAP or CSV.
    Glad you acknowledge this. This is exactly my point.

    I'm sorry, your point doesn't make any sense. I'll try again: object/relational mapping, by definition, is the mapping of objects to a relational database. Talking about ORM for non-relational databases is nonsense. We can talk about object persistence for non-relational databases, or queries for non-relational databases, but talking about ORM for non-relational databases is like talking about a hat for your leg. It has no meaning.
    Are you suggesting that GROUP, HAVING etc. do nothing but throw exceptions?

    As I have said numerous times, the full JDO spec, including all of JDOQL, is supported on non-relational stores.
    Well DB vendors spent decades perfecting their relational engines and underlying file and even device formats. Why should I trust JDO doing that right and in scalable?

    "ODB vendors spent decades perfecting their object persistence engines and underlying file and even device formats. Why should I trust RDBs and ORM tools doing that right and scalable?"

    The above tongue-in-cheek rewording of your quote illustrates the inconsistency in your position. You say that only relational databases should be used for object persistence, yet they weren't designed for object persistence at all. You point out how inefficient some querying operations are on non-relational stores compared to a RDB, and you ignore how inefficient some object persistence operations are on a RDB compared to an ODB. If you want to be consistent, you should be advocating the abolishment of all ORM tools, and the use of ODBs for all object persistence!

    Also, no one is asking you to "trust" anything. JDO is here and it works. You don't have to take anyone's word for it. You can download it and use it right now. That is why your position is untenable. You're trying to tell us all that JDO doesn't work for non-relational stores, when many of us have actually used JDO on non-relational stores with great success. No amount of your rhetoric is going to change the fact our projects were successful and JDO helped us make them successful.
    I agree, we can do it (JDO2 atop flat something) , still convinced that we should NOT do it.

    Then don't! Only use it against RDBs if that's what you want to do. Or don't use it at all. But some developers have found JDO on top of both relational and non-relational stores quite useful. These developers are solving real-world problems with JDO. You've never used JDO and don't seem to have a good understanding of it. Who are you to tell these developers they're wrong?
  76. n[ Go to top ]

    One size does NOT fit all. That is exactly why JDO should not be approved till it has a nonsensical claim of storage independence.

    I have never understood this point of view. I want to have common JDO code that can, in principle store to a variety of formats: relational store, XML files, object database... whatever my customer wants. If they want to store thousands of objects on a relational store, or just a few in an XML file - why should I impose a restriction? Sometimes I think that the objection is because of a mistaken belief that every JDO implementation has to support storage independence. This is not the case - I can pick a JDO product for the desired storage method. Some products may specialise in relational storage, some in object databases, other in XML/CSV files or whatever. That is the beauty of having a multi-vendor standard.

    I don't understand how a claim of storage independence can be nonsense when it works and it is being used in this way.
  77. JDO 2.0[ Go to top ]

    Sorry - parent post should have had topic 'JDO 2.0'
  78. 1. We need a fully fledged lightweight persistence standard between now and EJB 3 in 2006/7.
    2. Tens of thousands of customers currently using JDO shouldn't be abandoned by the JCP which promised them JDO 2 with JSR 243.
    3. If the vote doesn't pass, then everyone will *think* that's it's because of politics not technical reasons, and the JCP will lose credibility.
    4. Around 25 open source and commercial implementations wouldn't go away - they'd either fork or create their own standards body outside the JCP.
    5. Hibernate is great, but it's still a proprietary (i.e. vendor-specific) API, so you lose portability if you use it.
    6. The promise of an EJB 3 similar to JDO shouldn't mean we kill off JDO. Choice is a good thing (JDBC, JDO, EJB CMP, EJB BMP, EJB 3) - let the market decide.
    7.
    8.
    9.
    10.

    I'll leave 7-10 for others to fill in...

    btw - if you don't want JDO to be killed off within the JCP, then send an email to the Executive Committee letting them know you want them to vote in favour of JSR-243:

    http://www.jcp.org/en/participation/committee#SEEE

    Sending an email to the 11 members that voted no or abstained is a much better way to help JDO 2 cross the line than posting to the server side (so do both :)

    cheers,

    Dave.
  79. Choice is a good thing (JDBC, JDO, EJB CMP, EJB BMP, EJB 3)

    Could not agree more! One size does NOT fit all. Every project and every development team has its own requirements and skillset.

    I'll leave 7-10 for others to fill in...

    7. Technical merit (really, I know that won't make any difference to the no voters, but still ...)
    8. Don't waste all the hard work done on 2.0 of the specification team.
    9. If JDO is voted down, it will be much harder for Sun and the JCP to rally ISVs around future specifications. JDO has a very healthy ecosystem of vendors support it.

    I'll leave point 10, and the final word, to someone else..


    PJ Murray
     CodeFutures Software
  80. I guess another reason would be:

    10. Other persistence APIs (including EJB 3 POJO persistence) aren't as well designed for non-relational datastores as JDO is. For example - ODBMS's, XML, LDAP, Flat files, Persisting to remote services in an SOA, etc.

    That makes ten. Does anyone have any other favourite reasons they use JDO?

    cheers,

    Dave.
  81. Awesome grassroots support[ Go to top ]

    It's been really good to see so many people come out in support of JDO. For the most part, the JDO proponents have tended to walk softly. But as Teddy Roosevelt said, "walk softly, but carry a big stick".

    -geoff
  82. Hibernate but still[ Go to top ]

    I use Hibernate, but still. The impression I got was the vote against JDO was mostly political. YUCK! I hope it passes this next round. I agree that the impression is that the JCP process is very pro vendors with political clout. This soils the reputation of the process.

    I will likely continue to use Hibernate no matter what the outcome. We get a lot of Hibernate consulting work. The only JDO work I've done was to help a company port from JDO to Hibernate. (This is market driven and is not statistically significant... just emperical (sp?) knowledge).
  83. Hibernate but still[ Go to top ]

    I use Hibernate, but still. The impression I got was the vote against JDO was mostly political. YUCK! I hope it passes this next round. I agree that the impression is that the JCP process is very pro vendors with political clout. This soils the reputation of the process.

    I think it's far worse for the JCP than that. If an existing JCP specification/standard already in use by a large number of developers and supported by major vendors is effectively deprecated by the JCP, the damage to the JCP could be very serious indeed. It has already suffered significant damage to its reputation through the previous 'no' vote on this matter.

    The JDO 2.0 specification will survive a final 'no' vote - it (or an equivalent) is going to be implemented (under another name if necessary) outside of the JCP. It is questionable as to whether the JCP itself would be viable after such a vote.
  84. Vote for JDO[ Go to top ]

    JDO Central has an online petition you can sign to show your support for JDO:

    http://www.jdocentral.com/JDO_SignOurPetition_Form.html
  85. This looks like JDO version 3[ Go to top ]

    http://www.prevayler.org/wiki.jsp
    It says it's 9,000 faster than Oracle ...

    More:
    http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ

    JDO folk seem to be saying this:
    http://www.prevayler.org/wiki.jsp?topic=PrevalentManifesto

    I'll just call it OrM (small R) vs SQL baser E/R tools (Apache iBatis, RowSet, Spring JDBC .. ) (+ all the sucessfull P-lang applictions )

    .V
  86. Committee please terminate JDO[ Go to top ]

    JDO is dead for political reasons. That’s good! JDO should be terminated for technical reasons also. Here is why:

    Good object persistence APIs are non-intrusive. You just have to change the Database#store() method from one vendor to the next and you are done. A modern refactoring IDE will do that for you on any application in seconds. Accordingly the value of a “standard” on how the #store() method is called is ~zero. You run no risk if you use a proprietary solution.

    The most work and value that needs to be put into application persistence will go into writing code that queries the database. This is where a standard is badly needed to make persistence layers interchangeable. Hower this is where JDOQL is flawed most, a conglomerate of Java-Code-as-Strings, very bad to read, write, maintain, debug and refactor.

    Here is how JDOQL looks like:
    Query q = pm.newQuery (Employee.class, “salary > sal”);
    q.declareParameters (“Float sal”);
    q.setOrdering (“salary ascending”);
    Collection emps = (Collection) q.execute ();

    Here is how typesafe object querying should look like:
    Query q = database.query();
    q.from(Employee.class)
    q.where(“salary”).greater(sal).orderAscending();
    Collection emps = (Collection)q.execute();

    Notice that Strings are ommitted at all costs. The last remaining string “salary” is due to a Java deficiency to access fields in a refactorable way. Here is an RFC to improve this

    Some more arguments can be found on my blog.

    Please stop JDO !

    Let’s do it right.
    --
    Carl Rosenberger
    Chief Software Architect
    db4objects Inc.
    http://www.db4o.com
  87. Committee please terminate JDO[ Go to top ]

    Move query to view or procedure, if you do not like strings in JAVA, it will help to reuse queries in all your applications connected to your database (I asume you use the database management system). Modern ORM tools do not have this problem.
  88. Committee please terminate JDO[ Go to top ]

    Move query to view or procedure, if you do not like strings in JAVA, it will help to reuse queries in all your applications connected to your database (I asume you use the database management system). Modern ORM tools do not have this problem.
    Your suggestion makes things a lot worse: It forces to write, maintain, debug and pass parameters to three layers - Relational, Java, Procedures.

    Only people that get payed per hour for spent time may have a reason to choose this approach.

    No, I do not use a relational database. I work on an open source object database that let's you store and query with plain Java objects: db4o.
  89. Committee please terminate JDO[ Go to top ]

    No, I do not use a relational database. I work on an open source object database that let's you store and query with plain Java objects: db4o.
    Try RDBMS before to reinvent databases and OOP.
  90. Ouch![ Go to top ]

    No, I do not use a relational database. I work on an open source object database that let's you store and query with plain Java objects: db4o.
    Try RDBMS before to reinvent databases and OOP.

    RDBMS and OOP don't have very much in common. Using an OODB is not reinventing OOP bc. its the same. It is *innovating*, not reinventing databases.
  91. Committee please terminate JDO[ Go to top ]

    Try RDBMS before to reinvent databases and OOP.
    I did for a decade and it didn't work. Here is how generated complex queries
    looked like. (see the end of the posting)

    That's why db4o was started.
  92. Committee please terminate JDO[ Go to top ]

    Try RDBMS before to reinvent databases and OOP.
    I did for a decade and it didn't work. Here is how generated complex queries looked like. (see the end of the posting)That's why db4o was started.
    You need to learn modeling and views if your queries look this way.
  93. Committee please terminate JDO[ Go to top ]

    [complex query sample]
    You need to learn modeling and views if your queries look this way.
    How can you be so sure? Did you read the requirements of the product and did you see what the generator could do?

    Actually I love these "you need to learn" arguments. One nice point about using an object database and about simply persisting the scheme that you use in your application is that you do not need to learn anything else. Program OO, store objects, query with objects, it's that simple.
  94. Committee please terminate JDO[ Go to top ]

    [complex query sample]
    You need to learn modeling and views if your queries look this way.
    How can you be so sure? Did you read the requirements of the product and did you see what the generator could do?Actually I love these "you need to learn" arguments. One nice point about using an object database and about simply persisting the scheme that you use in your application is that you do not need to learn anything else. Program OO, store objects, query with objects, it's that simple.
    Yes, it is fine to use object databases, but it is not a reason to discredit SQL and RDBMS using your own crappy query as example. I do not want to insult you, I make a lot of mistakes too, but learning helps to fix it (I learn a lot of technologies including JDO). I recommend to try it, probably it will help to write better queries too. It can help to implement better object database too.
    I see it become very popular to blame SQL using "complexity" argument, but it was never easy to develop high quality applications. Many applications need more functionality than "persistence" and RDBMS helps a lot.
    It is possible to understand your motivation, but it is hard to understand JDO expert motivation to discredit SQL, industry standards,science,drivers and relational model.
  95. Committee please terminate JDO[ Go to top ]

    Many applications need more functionality than "persistence" and RDBMS helps a lot.

    Absolutely.
    It is possible to understand your motivation, but it is hard to understand JDO expert motivation to discredit SQL, industry standards,science,drivers and relational model.

    I'm not an expert, but I haven't noticed anyone discrediting SQL, standards, science or drivers, simply honestly recognising the fact that SQL implementations and drivers have differences, and to make best use of an implementation you have to take these differences into account.

    SQL and relational theory was one of the most important innovations in the history of IT. JDO has never tried to discredit it - good JDO implementations not only use SQL, but produces good quality SQL customised for particular databases - how can that possibly be called discrediting?

    My motivation for using JDO is simple: I like to work in Java. I like to express what I am doing in Java. Also, I have clients that want to choose what databases they deploy my application on. JDO does the work of supporting the variants of SQL that those databases use. It is fast (fast enough for me), easy to use, and the JDO product I use has great visual tools for Object/Relational mapping, schema design, and run-time profiling. It makes things so much easier for me, and even better - it conforms to a JCP standard! Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?

    I really can't understand the objection to this.
  96. Committee please ratify JDO 2 !![ Go to top ]

    My motivation for using JDO is simple: I like to work in Java. I like to express what I am doing in Java. Also, I have clients that want to choose what databases they deploy my application on. JDO does the work of supporting the variants of SQL that those databases use. It is fast (fast enough for me), easy to use, and the JDO product I use has great visual tools for Object/Relational mapping, schema design, and run-time profiling. It makes things so much easier for me, and even better - it conforms to a JCP standard! Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?

    Well put Steve! I agree wholeheartedly!
    I really can't understand the objection to this.

    Either can I.

    If your application has a strong domain object model, then JDO is a God Send.

    Having used JDO 1.0.1 successfully on a couple of enterprise projects now, I cannot wait for the newly standardized features present in JDO 2.0. The JCP MUST vote yes on this version of the spec! They cannot let FUD & politics get in the way of such a technically strong specification.

    In past projects (seems like past lives now) I have used TopLink, CocoBase, and EJB Entity Beans (1.0 up to 2.1) and none of them have approached the problem of persisting a domain object model with the elegance of JDO. None!
  97. Committee please terminate JDO[ Go to top ]

    Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?
     I do not need SQL for everything, I need it to access RDBMS, I do not need JDOQL for everything too.
    I see no technical problem to support standard SQL in JDO and I do not think bug in driver or "object database" marketing BS like "impedence mismacth" is a reason to ignore mature industry standards. If it is out of JDO scope to support RDBMS with SQL then alternative solution for this problem is a new data access framework standard. EJB3 is very far from mature specification, but it can be a solution too. Standard ways like JDOQL, "native" query or plain JDBC is not a good solution for me.
  98. Committee please terminate JDO[ Go to top ]

    Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?
    &nbsp;I do not need SQL for everything, I need it to access RDBMS, I do not need JDOQL for everything too. I see no technical problem to support standard SQL in JDO and I do not think bug in driver or "object database" marketing BS like "impedence mismacth" is a reason to ignore mature industry standards.

    Have you even looked at the JDO 2.0 specification?!?!

    Standard SQL IS supported in JDO!
  99. Committee please terminate JDO[ Go to top ]

    Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?
    &amp;nbsp;I do not need SQL for everything, I need it to access RDBMS, I do not need JDOQL for everything too. I see no technical problem to support standard SQL in JDO and I do not think bug in driver or "object database" marketing BS like "impedence mismacth" is a reason to ignore mature industry standards.
    Have you even looked at the JDO 2.0 specification?!?!Standard SQL IS supported in JDO!
    Are you talking about "native" query hack ?
  100. Committee please terminate JDO[ Go to top ]

    Of course there are things that pure SQL has to be used for but why should it be used for absolutely everything?
    &amp;amp;nbsp;I do not need SQL for everything, I need it to access RDBMS, I do not need JDOQL for everything too. I see no technical problem to support standard SQL in JDO and I do not think bug in driver or "object database" marketing BS like "impedence mismacth" is a reason to ignore mature industry standards.
    Have you even looked at the JDO 2.0 specification?!?!Standard SQL IS supported in JDO!
    Are you talking about "native" query hack ?

    No.

    I am talking about JDO's elegant support for query languages other than JDOQL. Please see JDO 2 specification section "14.7 SQL Queries" for more information.
  101. Committee please terminate JDO[ Go to top ]

    No.I am talking about JDO's elegant support for query languages other than JDOQL. Please see JDO 2 specification section "14.7 SQL Queries" for more information.
    Ok, It sounds better. We discussed it many times and I like this JDO feature. If JDO is going to support and improve it then I am JDO supporter too. There are two ways to improve it in specification:
    1) Define formal object motel and mapping to relational model, JDOQL to relational calculus translation. It will be possible to "calculate" JDOQL power without FUD in this case.
    2) Make SQL a "first class" query language. There is nothing to invent in this case.
     Single problem can be a specification scope, I can understand it too. This problem can be solved using a new data access framework specification.
  102. Committee please terminate JDO[ Go to top ]

    JDO is dead for political reasons.

    Nonsense. Thousands of developers and major vendors disagree with you.
    That's good!

    Yeah, the JCP deprecating a widely used and implemented standard - what a great step forward for Java!
    Hower this is where JDOQL is flawed most, a conglomerate of Java-Code-as-Strings, very bad to read, write, maintain, debug and refactor.

    Having a more readable query syntax is one of the changes in JDO 2.0.

    Having the query as a string is a good idea. It allows the query to be externalised from the program, so it can tested and optimised and tuned separately.
    Please stop JDO !Let’s do it right.--Carl RosenbergerChief Software Architectdb4objects Inc.http://www.db4o.com

    Don't you think a more professional attitude might be to stop actively attacking a technology that thousands of developers use, and simply offer them the choice of a supposedly better product? If this product is better, developers will use it anyway.
  103. Committee please terminate JDO[ Go to top ]

    JDO is dead for political reasons.
    Nonsense. Thousands of developers and major vendors disagree with you.

    I forgot a comma: should read 'Thousands of developers, and major vendors..'

    Even I don't suggest that thousands of vendors are implementing JDO!

    Apologies
  104. Committee please terminate JDO[ Go to top ]

    Thousands of developers
    Hundreds at most, judging by the traffic on JDOCentral and in vendors newsgroups.
    and major vendors
    Please name one "major vendor" with a complete JDO implementation. I can only see small shops, all public ones have had deficits for years.
    Having a more readable query syntax is one of the changes in JDO 2.0
    My example is taken from 2.0.
  105. Committee please terminate JDO[ Go to top ]

    Carl:
    Here is how JDOQL looks like:
    Query q = pm.newQuery (Employee.class, “salary > sal”);
    q.declareParameters (“Float sal”);
    q.setOrdering (“salary ascending”);
    Collection emps = (Collection) q.execute ();

    Steve:
    Having a more readable query syntax is one of the changes in JDO 2.0

    Carl:
    My example is taken from 2.0.

    Yes, Carl, since JDO 2.0 is backward compatible with JDO 1.0.1 you are right - your query is valid JDOQL. However, there is a more elegant way to which Steve was referring, and which I have already pointed out to you:

    Query q = pm.newQuery ("SELECT FROM com.hr.Employee WHERE salary > :sal ORDER BY salary ascending");
    Collection emps = (Collection) q.execute (12345.67);
  106. Committee please terminate JDO[ Go to top ]

    However, there is a more elegant way to which Steve was referring, and which I have already pointed out to you:Query q = pm.newQuery ("SELECT FROM com.hr.Employee WHERE salary > :sal ORDER BY salary ascending");Collection emps = (Collection) q.execute (12345.67);
    Now that is plain SQL, isn't it? Where does JDO come in to produce a standard for querying?

    IMHO your solution is not elegant at all, it is awful. I have pointed out a zillion times why I think that it is a bad idea to construct queries with strings. Here is a repost of some reasons:

    - Typos are not checked by the IDE.
    - Automatic refactorings are not available.
    - Modular construction of queries is much more difficult with delegated method calls.
    - Strings consume ressources in the app library.
    - Strings need time to get parsed.
    - Strings can be subject to injection attacks.

    Apparently the JDO folks are so lost at tweaking their string constructs to meet developer needs that they don't find the time to look from the distance - to see how ugly this beast has become. Have a look at this thread on JDOCentral as a proof.
  107. Committee please terminate JDO[ Go to top ]

    Now that is plain SQL, isn't it?

    Nope. This query is expressed in terms of the domain object model (classes e.g. "Employee", and fields e.g. "name") and not tables and columns. This query is independent of the underlying mapping, so it doesn't matter what table Employee lives in or what column the name lives in. Coincidentally the query is portable across all JDO implementations which support JDO 2.0 regardless of database paradigm.
    Where does JDO come in to produce a standard for querying?

    There is no credible pre-existing standard for expressing queries in terms of the domain model. JDO has a mandate for this from JSR-12.
  108. String-based Queries[ Go to top ]

    Carl makes the following comments about String-based Queries:

    - Typos are not checked by the IDE.

    Correct. But my queries are all covered by dedicated JUnit tests which will quickly tell me if I have broken the query either syntactically or semantically. IDE checks only verify syntax.

    - Automatic refactorings are not available.

    Correct.

    - Modular construction of queries is much more difficult with delegated method calls.

    I'm not quite sure to what you are referring. Certainly building queries dynamically requres String concatenation when working with the single-string form of JDOQL.

    - Strings consume ressources in the app library.

    Feel free to externalize the strings. JDO 2.0 has standardized the representation of an externalized Query, as well as the API by which it can be invoked - pm.newNamedQuery(...).

    - Strings need time to get parsed.

    I guess this is the crux. I am prepared to let the JDO implementation parse the query string and build the query tree, safe in the knowledge that a good implementation will do this only once. You prefer that the developer build the tree. This is a valid approach, but appears to have relatively little support in the developer community (in my experience).

    - Strings can be subject to injection attacks.

    Feel free to externalize the strings.

    Kind regards, Robin.
  109. Committee please terminate JDO[ Go to top ]

    Thousands of developers
    Hundreds at most, judging by the traffic on JDOCentral and in vendors newsgroups.

    Hundreds! This is nonsense. Are you seriously suggesting that the only developers that count are those that post on forums? How about counting downloads of products? Registered product users? There are around 500 registered users of JPOX alone, and that is just one implementation. JDO has a significant presence in commercial enterprise development - just look at the customer lists of the JDO vendors.

    All this has been argued out on previous threads. I don't understand why this FUD persists.
    I can only see small shops, all public ones have had deficits for years.

    More nonsense. Large shops: Versant, Xcalia, Solarmetric for example.

    By what definition are you calling Versant a 'small shop'? Perhaps you would like to list the deficits in the public versions?
  110. Committee please terminate JDO[ Go to top ]

    There are around 500 registered users of JPOX alone, and that is just one implementation.

    Yet another mistake on my part (I must post more slowly). I mean 500 registered forum users. The number of developer is, of course, much greater.
  111. Committee please terminate JDO[ Go to top ]

    Hundreds! This is nonsense. Are you seriously suggesting that the only developers that count are those that post on forums?
    The number of serious developers working on serious productive projects obviously is by far smaller than the number of developers posting to a forum. Just look at the most frequent questions: "Hey I am trying this out."
    There are around 500 registered users of JPOX alone, and that is just one implementation.
    500 is a figure of a very small niche product. We have had far more than 100,000 downloads in the lifetime of our product and 2,000 new registered (not necessary to download) users in the past three months since going open source.
    ...and I wouldn't call our product mainstream yet.
    JDO has a significant presence in commercial enterprise development - just look at the customer lists of the JDO vendors.
    Obviously all vendors brag with customer names, but wouldn't you expect some significant revenues from these enterprise customers?
    Large shops: Versant, Xcalia, Solarmetric for example. By what definition are you calling Versant a 'small shop'?
    By license revenues and profit, see the above link, and by the development budget that is being spent to develop 6 different products with a different codebase, four of them recently acquired, one old, one not released yet.
  112. Committee please terminate JDO[ Go to top ]

    500 is a figure of a very small niche product. We have had far more than 100,000 downloads in the lifetime of our product and 2,000 new registered (not necessary to download) users in the past three months since going open source.
    ...and I wouldn't call our product mainstream yet.

    In your site you say more than 100,000 DEPLOYMENTS and NOT DOWNLOADS.
  113. 500 is a figure of a very small niche product... We have had ... 2,000 new registered (not necessary to download) users in the past three months since going open source

    that's because one can't make any use of your web site unless registered (well, apart from looking at the datasheet and the marketing stuff)

    so, the "2000 new registered" users is not much of an argument. Most of them were probably just curious and will never be active users (e.g. even give db4o a try)
  114. that's because one can't make any use of your web site unless registered
    ...except for downloading our product, where we currently measure a rate of 300 completed downloads per day, with a strong tendency to increase, after being bundled with Mono.
  115. Committee please terminate JDO[ Go to top ]

    500 is a figure of a very small niche product.

    That was just people registered to chat on the forum. The site stats show nearly 30,000 downloads. Even if a fraction of those convert to actual use, it shows your that your figure of 'hundreds' for total JDO use is nonsense. Remember, this is only one JDO implementation, and one that does no marketing of its product.
  116. Committee please terminate JDO[ Go to top ]

    Don't you think a more professional attitude might be to stop actively attacking a technology that thousands of developers use,
    Attempting to stop the wrong trend is VERY professional and socially responsible attitude.
    and simply offer them the choice of a supposedly better product? If this product is better, developers will use it anyway.
    Unfortunately people do not follow 'better' ways even they know that something is better.
    Example: everybody knows that “eat less - exercise more” is the right way, but look around, what percent of people do that? and how many are obese lazy TV drones?
  117. Committee please terminate JDO[ Go to top ]

    Don't you think a more professional attitude might be to stop actively attacking a technology that thousands of developers use,
    Attempting to stop the wrong trend is VERY professional and socially responsible attitude.
    and simply offer them the choice of a supposedly better product? If this product is better, developers will use it anyway.
    Unfortunately people do not follow 'better' ways even they know that something is better. Example: everybody knows that “eat less - exercise more” is the right way, but look around, what percent of people do that? and how many are obese lazy TV drones?

    My point was that no matter how bad you think a technology is, I believe you don't get very far in marketing competing products by trying making those who have adopted that technology feel like you are attacking them and their IT strategy, and trying to stop them using a technology they have invested time and money in. It is entirely fair to explain why your product is better, and to encourage migration to it, but implying that people are incompetent for having chosen their particular product, and actively working to stop future support for that product, is not a good way to make friends or gain customers. But that is just my view.
  118. Don't you think a more professional attitude might be to stop actively attacking a technology that thousands of developers use,
    Attempting to stop the wrong trend is VERY professional and socially responsible attitude.
    Konstantin,

    can you provide us any factual evidence that JDO is a wrong trend? I am not interested in your personal opinion, but in unbiased technical facts only.

    Regards,
    Henrique Steckelberg
  119. >Konstantin,can you provide us any factual evidence that JDO is a wrong trend? I am not interested in your personal opinion, but in unbiased technical facts only.Regards,Henrique Steckelberg
    Ah Henrique, please give a fact that does not need {opinionated} interpretation.

    Please reread arguments against JDO and think about them if you are really interested. Or feel free to move ahead and dismiss everything in a flat denial.
  120. >Konstantin,can you provide us any factual evidence that JDO is a wrong trend? I am not interested in your personal opinion, but in unbiased technical facts only.Regards,Henrique Steckelberg
    Ah Henrique, please give a fact that does not need {opinionated} interpretation. Please reread arguments against JDO and think about them if you are really interested. Or feel free to move ahead and dismiss everything in a flat denial.
    Ok, I guess my quest to find any proof that JDO is flawed is over: there isn't any to be found. I keep rereading these posts against JDO, and what I have understood from JDO haters is one or a combination of the following:
    - they support competing products/standards/solutions, and can't deal with competition
    - they are so entrenched into some technology they can't accept the fact that there are other lines of work besides their own
    - they are rather religious about their concepts and beliefs, so that when someone proves them 2+2=4, they refute by saying: This is wrong because I know it is, and that's it.
    - they are plainly trolling and have nothing to do besides try to find a tiny hole in people's reasoning, endlessly and fruitlessly, for their own amazement.

    There is not one argument in any JDO thread up to now proving JDO is flawed. Some of the arguments go as far at to prove JDO is not adequate for some situations (which is obvious, there is not one solution which fits all problems), or that there are better solutions in other situations (competition is good), but none of them proves JDO has to be dismissed altoguether or is flawed to the point of being unusable at all. So all these argumenting about "JDO must die" or "JDO is wrong" is rather pathetic.

    How is possible that there are people in such a technical area as IT with this kind of misbehavior, is something I find hard to understand. This is not religion, politics, or sports, there is nothing here to be won, feared or killed.

    Open your minds,
    Henrique Steckelberg

    PS: I am not related to any JDO vendor, product, tool or framework.
  121. There is not one argument in any JDO thread up to now proving JDO is flawed.
    That may be a correct summary for your usecases, Henrique, it may be wrong for others.

    We supply an object database that is intended to provide maximum performance on low ressource systems where parsing strings is simply not an option.

    We managed to provide completely non-intrusive persistence - no class has to be enhanced or poluted with an interface to store it. Why should be back away from additional ease-of-use?

    Instead of having JDO taking attention away from our product I would love us to have a standard that we could endorse also, to fight the relational world together, with joined force.

    I do believe that JDO is flawed and I am sure that anyone who has constructed complex queries with JDOQL shares my opinion.

    This is not a political war, religion or anything else. JDO is ruining our market and giving object persistence a bad name as "awkward to use".

    An object persistence API has a chance to improve on SQL, with concepts like Query-By-Example (as we provide it) and with a solution for object-oriented isolation management. JDO is just not good enough.
  122. Committee please terminate JDO[ Go to top ]

    An object persistence API has a chance to improve on SQL, with concepts like Query-By-Example (as we provide it) and with a solution for object-oriented isolation management. JDO is just not good enough.
    Query-By-Example is not a very popular (dead dinosour), but it was one of relational languages too http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter5/node2.html
    Try to learn this stuff before to sell it.
  123. That may be a correct summary for your usecases, Henrique, it may be wrong for others.
    The same could be said about YOUR product, couldn't it? Or does is fit absolutely any and all use case out there?
    We supply an object database that is intended to provide maximum performance on low ressource systems where parsing strings is simply not an option.
    Ok, you'd rather do things differently, no problem. Are you sure everybody else agrees with you? Where have you got this higher knowledge of what every developer out there needs and wants? Can you borrow some of it? :)
    We managed to provide completely non-intrusive persistence - no class has to be enhanced or poluted with an interface to store it.
    So has JDO, as Robin already pointed many times. Have you read latest JDO specs?
    Why should be back away from additional ease-of-use?
    I find your query tree construction API rather complicated when compared to pure string queries. This is all a matter of taste, and you just can't tell someone what his taste should be.
    Instead of having JDO taking attention away from our product...
    That's the fear of competition going on again. Fear no more: JDO is your friend. It will ease the migration from RDBMS to ODBMS, and that can actually help YOUR product, in the end. Have you thought about that?
    I would love us to have a standard that we could endorse also, to fight the relational world together, with joined force.
    There's the fear of competition once more. No need to fear RDBMS, they are our friends too. We need to bring it closer to other solutions, so we are able to choose the best one for the job at hand. JDO will help this happen. But there is no point in trying to fight AGAINST relational, it is here to stay, it is a pointless fight.
    I do believe that JDO is flawed and I am sure that anyone who has constructed complex queries with JDOQL shares my opinion.
    You BELIEVE? Is it really about faith? Or is there a technical flaw which prevents you from achieving your goals? So far I haven't seen any evidence of JDO flaws, just some people complaining it isn't exactly like they want it to be.
    This is not a political war, religion or anything else. JDO is ruining our market and giving object persistence a bad name as "awkward to use".
    How can you say it is not political, and on the next phrase say it is ruining your market? Don't fear JDO, instead embrace it as it may actually help sell your product. Take the chance of putting your product to compete face-to-face with others, and have it show it really outperform them as you are telling us it does, I am sure it will do nothing but help increase DB4O adoption.
    An object persistence API has a chance to improve on SQL, with concepts like Query-By-Example (as we provide it) and with a solution for object-oriented isolation management. JDO is just not good enough.
    Ok, so it is not flawed, just not good enough. Much better now! :) Why not take the chance of finally having this object persistence API standard by taking this "not good enough" one and improving it, instead of creating another one from scratch, something which will surely take much longer?

    Every challenge is a chance to improve. Don't miss it.

    Regards,
    Henrique Steckelberg
  124. I would love us to have a standard that we could endorse also, to fight the relational world together, with joined force.
    There's the fear of competition once more. No need to fear RDBMS, they are our friends too. We need to bring it closer to other solutions, so we are able to choose the best one for the job at hand. JDO will help this happen. But there is no point in trying to fight AGAINST relational, it is here to stay, it is a pointless fight.
    This stuff is know as aggressive marketing a.k.a FUD. It is not a fear of competition, it is an attempt to provoke competition. I am not marketing expert, but the worst thing for marketing is an ignorance (FUD is not a bad thing in this context)
  125. FUD is bad[ Go to top ]

    This stuff is know as aggressive marketing a.k.a FUD. ... (FUD is not a bad thing in this context)

    I think there is a huge difference between FUD and aggressive marketing. FUD is very bad the for IT industry in the same way that spin doctoring is bad for politics - it leads to a lack of trust. Developers and IT managers expect to make decisions based on correct information and honest opinions. With all the FUD around, it becomes hard to put forward any opinion without being suspected of bias. FUD poisons any debate. This is why I think that vendors who rubbish JDO for political reasons (usually without being honest that their reasons are political, not technical) are in the long term damaging themselves.
  126. FUD is bad[ Go to top ]

    This is why I think that vendors who rubbish JDO for political reasons (usually without being honest that their reasons are political, not technical) are in the long term damaging themselves.
    Some vendors have nothing to lose anyway.
  127. FUD is bad[ Go to top ]

    FUD the fudding fudders, as George Carlin might say. Every word written is FUD - from the perspective of someone who disagrees with the premise of the writer.

    There are those who seem to have been born 'different' and think the world is constantly against them. So, they bring that personal bias into their entire worldview and see political "conspiracy and evil" even where none exists. However, those sort of people quickly loose all credibility, much like the boy who cried wolf.

     - Don
  128. FUD is bad[ Go to top ]

    FUD the fudding fudders, as George Carlin might say.

    Carlin is a wise dude.
    Every word written is FUD - from the perspective of someone who disagrees with the premise of the writer.

    I think that this is far too cynical a view. It is (I hope) possible to debate using reasoned argument based on evidence. For example, even though I am a supporter of JDO (because I like to be able to have alternate vendors), I believe that JDO 1.0 lacks some important features, and I have recommended the use of Hibernate in some projects. FUD consists of statements such as 'Hibernate is slow' or 'no-one uses JDO': statements which are easily refuted by evidence, but are put forward for political or marketing reasons. Often FUD is a point of view or an opinion being put forward as if it were a fact.

    Perhaps it is because of my background as a scientist - I am used to disagreeing with a premise without assuming that the writer is trying to attack me personally, even if I may occasionally get frustrated or impatient with what I read!
  129. Committee please terminate JDO[ Go to top ]

    I would like to complement you on an excellent summary of the situation.
    How is possible that there are people in such a technical area as IT with this kind of misbehavior, is something I find hard to understand. This is not religion, politics, or sports, there is nothing here to be won, feared or killed.

    I think there is. When JDO 2.0 becomes a standard for persistence (hopefully within the JCP, or if not, as a multi-vendor-supported API outside the JCP), there will be pressure on many other persistence products to be compatible. If they implement the JDO specification, then the quality of their persistence engines can be measured up against the quality of other JDO implementations. They will then be subject to competition. JDO, if within the JCP, will be subject to compatibility tests. You won't be able to implement only a subset of the query language (as MySQL did with SQL) and call yourself 'compatible'.

    I can see why producers of proprietary persistence products may be wary of JDO.
    I am not related to any JDO vendor, product, tool or framework.

    Me neither.
  130. How is possible that there are people in such a technical area as IT with this kind of misbehavior, is something I find hard to understand. This is not religion, politics, or sports, there is nothing here to be won, feared or killed.

    Are you serious? Do you really think that standardization efforts are altruistic endeavors?

    Mentioning of sport is really funny – it is hard to find any other thing that LESS affect an individual, besides fattening a… when watching games and driving chips and beer sales.
    they are so entrenched into some technology they can't accept the fact that there are other lines of work besides their own

    Some definitely are, but I guess you mistake them for people who do understand technologies really well, know their strengths and WEAKNESSESS and really frustrated because that ‘new’ stuff does not provide any substantial improvements. Quite contrary hungry and loud youngsters make things worse because of ignorance.

    Unfortunately way to many rebels see (even just heard about) weaknesses of a given technology and just do not understand strengths and reasons for those weaknesses. And some so-called weaknesses are plain imaginary and caused by misunderstanding of the domain.
  131. Committee please terminate JDO[ Go to top ]

    >Konstantin,can you provide us any factual evidence that JDO is a wrong trend? I am not interested in your personal opinion, but in unbiased technical facts only.Regards,Henrique Steckelberg
    Ah Henrique, please give a fact that does not need {opinionated} interpretation. Please reread arguments against JDO and think about them if you are really interested. Or feel free to move ahead and dismiss everything in a flat denial.
    Ok, I guess my quest to find any proof that JDO is flawed is over: there isn't any to be found. I keep rereading these posts against JDO, and what I have understood from JDO haters is one or a combination of the following:- they support competing products/standards/solutions, and can't deal with competition- they are so entrenched into some technology they can't accept the fact that there are other lines of work besides their own- they are rather religious about their concepts and beliefs, so that when someone proves them 2+2=4, they refute by saying: This is wrong because I know it is, and that's it.- they are plainly trolling and have nothing to do besides try to find a tiny hole in people's reasoning, endlessly and fruitlessly, for their own amazement.There is not one argument in any JDO thread up to now proving JDO is flawed. Some of the arguments go as far at to prove JDO is not adequate for some situations (which is obvious, there is not one solution which fits all problems), or that there are better solutions in other situations (competition is good), but none of them proves JDO has to be dismissed altoguether or is flawed to the point of being unusable at all. So all these argumenting about "JDO must die" or "JDO is wrong" is rather pathetic.How is possible that there are people in such a technical area as IT with this kind of misbehavior, is something I find hard to understand. This is not religion, politics, or sports, there is nothing here to be won, feared or killed.Open your minds,Henrique SteckelbergPS: I am not related to any JDO vendor, product, tool or framework.

    Well put Henrique Steckelberg! Well put. Thank you for saying what needed to be said.
  132. Committee please terminate JDO[ Go to top ]

    Here is how JDOQL looks like:
    Query q = pm.newQuery (Employee.class, "salary > sal");q.declareParameters ("Float sal");
    q.setOrdering ("salary ascending");

    In JDO 2, you could shorten that:

    Query q = pm.newQuery (Employee.class, "salary > :sal");
    q.setOrdering ("salary asc");
    Here is how typesafe object querying should look like:
    Query q = database.query();q.from(Employee.class).where("salary").greater(sal).orderAscending();

    First off, I think you're missing what to order by in your example, unless your system assumes that ordering is on the last-compared field, which seems a little odd. Other than that, I don't see how your style is much safer. How often do you mistype a greater-than sign when you write Java code? Do you think "asc" will be the cause of a lot of typos for JDOQL authors? I'd estimate that 90+% of query typing problems are typos in field names, or thinking a class has a field that it doesn't have; typos in operators are extremely rare.

    Neither system is typesafe. Both rely on stringified field names. That means that in both systems, you have to unit test, and that neither system can get assistance from an IDE when refactoring your objects. So if you have to unit test anyway, and you don't get refactoring assistance anyway, doesn't it makes sense to go with the more convenient query format? And the more convenient format is a String. The advantages of a String are:
    - More concise, as your example illustrates.
    - Can be entered directly by users and passed to the query framework. This is a major pain with method-based querying.
    - Can easily be passed around, read/written from/to text file, composed, regexp'd, etc.
    - Can be easily represented as named queries in metadata/annotations.

    Finally, I will point out three things:
    1. TOPLink used a system very similar to the one you're describing, and many users don't like it. I have experience with it myself. TOPLink folk are now on board with JSR 220, which uses single-string queries.
    2. JDO users called for *more* stringification of queries in JDO 2, resulting in the optional single-string JDOQL form Robin demonstrated earlier in the thread. Clearly, many users want the convenience of strings more than operator safety.

    And the most important point:
    3. JDO allows for other query languages! You could easily tack your query system onto JDO. Crying "Please stop JDO" because you think you have a better query solution seems extreme when that solution can easily be plugged into JDO.

    I'm sure some users will prefer your system over the current JDO one. But I believe that JDO has found the solution that is preferred by *most* users, and JDO's ability to use other query languages takes care of the rest. Why not start an effort to implement your query style on top of JDO, rather than calling for its termination? (And, I assume the termination of JSR 220, which uses string-based queries as well, but unlike JDO has no way to execute any other form...) I'm sure you'd find many users and an appreciative JDO community.
  133. Committee please terminate JDO[ Go to top ]

    In JDO 2, you could shorten that:
    Query q = pm.newQuery (Employee.class, "salary > :sal");
    q.setOrdering ("salary asc");
    There will be no JDO 2, for political reasons.

    ...well maybe Oracle, Bea and IBM could even decide to vote for JDO 2 to prevent a successful standard for object persistence by pretending to support a flawed one, but I doubt that they will have this insight on how to protect their own interests best.
    First off, I think you're missing what to order by in your example
    No.
    Query#where("fieldName"); is intended to work just like S.O.D.A. Query#descend("fieldName");
    It returns a reference to a descendant node in the constraint graph and all subsequent method calls on this node, except for #where(), will return the same node.
    Other than that, I don't see how your style is much safer.
    Yes it is, since it only contains one single string, one single fieldname that could very well be checked during development time by an Eclipse plugin. It would be great to remove this last string also with a Class#field notation. My "please use strings" argument may look small for this very basic example but it gets lots of importance when queries get more complex.
    And the more convenient format is a String.
    I am not saying that a string-based querying language should not be part of a persistance system, but it should not be the lowest level of the specification.

    Here are all the steps that are necessary anyway:
    (1) String SQL-like query =>
    (2) Parse =>
    (3) Tree representation =>
    (4) Query optimiser

    I suggest to standardize (3) first, because it is the most efficient place to do it and because all query processors need this representation anyway.

    Old JDOQL attempts to add a completely unnecessary level between (1) and (2).
    You could easily tack your query system onto JDO.
    Yeah, and I would also start building a skyscraper on an iceberg.

    Our query system works very well underneath a parser and without one, allowing to execute a couple of thousand queries per second on a regular PC. Why should we be happy with less?
    Crying "Please stop JDO" because you think you have a better query solution seems extreme when that solution can easily be plugged into JDO.
    I have been crying "Please stop JDO" for 4 years because I think it's flawed for a couple of more reasons.
    But I believe that JDO has found the solution that is preferred by *most* users
    No. Hibernate is preferred by most users. Guess why?
  134. Committee please terminate JDO[ Go to top ]

    No. Hibernate is preferred by most users. Guess why?

    <sarcasm>Let me guess now, ah, because it doesn't let queries be represented as strings but instead exposes methods by which to instantiate Query Object Model graphs?</sarcasm>
  135. Committee please terminate JDO[ Go to top ]

    No. Hibernate is preferred by most users. Guess why?
    <sarcasm>Let me guess now, ah, because it doesn't let queries be represented as strings but instead exposes methods by which to instantiate Query Object Model graphs?</sarcasm>
    You may be surprised at this one, in case you don't know yet:
    It does.

    Why don't you explain to me why Hibernate is more successful than JDO, Robin?

    JDO is full of flaws, it's not just querying. Every time I read your comments - like on my blog - I get the idea that you either do not notice them, do not understand them or belittle them, because of your personal interest in JDO.

    Clearly, the decision to back away from what you called "JDOQL" at first and to switch back to plain SQL is just like admitting "Hey, we were wrong, let's not specify a standard at all.".

    An object persistence layer would even be a chance for a standardized SQL layer - using a common graph like I propose - it would not only be possible to exchange "JDO" implementations, you could also switch relational databases in the back.

    ...now wait, let's rather not do that because it would be real political power, with even less chances to make it past the relational application server dinosaurs in the commmitee.
  136. Committee please terminate JDO[ Go to top ]

    <sarcasm>Let me guess now, ah, because it doesn't let queries be represented as strings but instead exposes methods by which to instantiate Query Object Model graphs?</sarcasm>
    You may be surprised at this one, in case you don't know yet:It does.

    As I said, that is trivial to implement on top of JDO. The fact that no vendor has done so is a testament to the fact that customers are not asking for it.
    Clearly, the decision to back away from what you called "JDOQL" at first and to switch back to plain SQL is just like admitting "Hey, we were wrong, let's not specify a standard at all.".

    What on earth are you talking about?

    Based on this thread and some of your other commentaries you've linked to, you seem to be have some major misunderstandings about JDO. The above quote is one example. Another is your talk about having to use enhancement... that requirement is long gone. Use reflection and state comparisons all you like.

    It is also clear that you are not being very objective in your appraisal of JDO. In the 2002 commentary you linked to, you rail on JDO about the overhead of the String argument to makeDirty, then say JDO implementations should all work by doing state comparisons instead of using enhancement's automatic dirty tracking. Do you really think matching a name to a field (a single Map lookup) in a rarely-used method is more overhead than reflection-based state comparison of every possibly-dirty field (including recursive comparisons of containers) in every transaction? In that same commentary, you say the String field name argument to makeDirty makes it an unsafe method... and yet your own supposedly-safe query system uses String field name arguments!

    I believe that you have some valid ideas and that your approach will appeal to some developers. But your insistence on calling JDO flawed whenever it takes a different tact that you, your calling out for the death of JDO when so many of the features you want can be plugged into an implementation so easily, and the obvious bias in your critiques of JDO really hurt your arguments.
  137. [Query by API]
    As I said, that is trivial to implement on top of JDO.
    This would be a bad idea for two reasons so I am not surprised that it hasn't been done by vendors:
    (Reason 1) What would you propose to your own userbase as the "standard" to program against? Your own query API addon or the default JDO interface that would allow users to change to another product? Obviously you would worry your users every decision they have to take.
    (Reason 2) Technically you would introduce additional steps to the querying process:
    (1) The user constructs a tree representation of the query.
    (2) This produces JDO strings.
    (3) These strings are parsed to produce a tree again.
    (4) The query is run from there.
    There is no benefit at all to offer (1) and (2) if you provide access to the much directer and faster level (3) directly.

    ["Hey, we were wrong, let's not specify a standard at all."]
    What on earth are you talking about?
    I am talking about the JDO spec backing away from the previous filter criteria API to supply SQL syntax instead, with the small addon of providing built-in parameter passing and with domains instead of tables. This is SQL, nothing else, and it does not solve the problem of incompatibilities between SQL dialects.
    Another is your talk about having to use enhancement... that requirement is long gone. Use reflection and state comparisons all you like.
    All right then, what is left of the specification if I can do all I like? My app will not be portable to some implementations if I rely on not having to use enhancement, right?
    In the 2002 commentary you linked to, you rail on JDO about the overhead of the String argument to makeDirty, then say JDO implementations should all work by doing state comparisons instead of using enhancement's automatic dirty tracking.
    Indeed, state comparisons are not an option at all for performance reasons, I agree on that. I was wrong (in 2001).
    and yet your own supposedly-safe query system uses String field name arguments!
    There is no way around using field or method names today so we can't help using them, althoug we think it is wrong. I have proposed this RFC to the Sun bug database three times, starting in 2001, and it only got accepted as an RFC in May 2004. The notations Foo#bar and Foo#bar() to specify fields and methods in a typesafe way without strings would allow us to have 100% refactorable queries.
    It is also clear that you are not being very objective in your appraisal of JDO.
    Obviously not. Indeed I do get excited occasionally and I may not serve my purpose best with my arguments. Maybe I am leading too many flame wars with relational proponents who come up with arguments like "object orientation does not follow sound mathematical principles" and "storing objects is stupid because you loose the independance of the application model from the data model".

    When I get into discussions with JDO people (shouldn't they be my friends?) I find myself arguing with 10 people at the same time that defend JDO and do not accept a single one of my points of criticism. To me this indeed feels like they all are completely ignorant. How can I stay objective? Would you?

    Let me explain our position again:
    We see the biggest future market for our open source object database embedded into devices. Ressource consumption is critical there. Startup time is. Query execution is critical also, very often in setups with a small number of objects and with complex queries.
    (1) String parsing, like it is necessary for JDO queries, is not an option for us.
    (2) We also expect our object database to be frequently used in replication setups. Objects will need to be replicated, copied and moved between databases, they may even have to exist in two databases at the same time. This is not possible with JDO, because objects keep a reference to their PersistenceManager. As a workaround Robin Roos suggests detach() using fetchgroups, but really that seems to much of hassle for our developers.
    (3) We would also like our users to have full control, what they store and update when. They need to be able to use our engine in non-transparent mode, with explicit calls to our #store() method. This method should also be able to update complete trees. JDO does not supply such an option, it's either transparent persistence or you work non-transactional or some objects are detached.

    For the above three reasons we just can't provide a JDO implementation targetted at our market it just won't work good enough.

    All of our approach would work very nicely together with JDO, as a layer underneath what you now deliver as "JDO". However it would not make sense for us to supply a JDO implementation on top of our engine ourselves. We would discredit our own API and we would distract our users from using what we think is the correct interface of our product.

    I have tried to get my ideas into JDO, maybe not with the right tone, but I couldn't help my reaction to "over my dead body" arguments and personal attacks. We will work on establishing another object persistence and querying standard:
    (1) at the lower level, where we think that standardisation should take place first:
    - with explicit update calls
    - using a querying API tree instead of strings that need parsing (to create a tree)
    (2) for .NET as well as for Java


    Do I make sense?

    --
    Carl Rosenberger
    Chief Software Architect
    db4objects Inc.
    http://www.db4o.com
  138. When I get into discussions with JDO people (shouldn't they be my friends?) I find myself arguing with 10 people at the same time that defend JDO and do not accept a single one of my points of criticism. To me this indeed feels like they all are completely ignorant.
    Are you telling me that if someone disagrees with you, it is just because they are ignorant? So there is zero chances you are mistaken, misinformed, or just have a different opinion about a specific subject, it that it? Were you expecting we all just go "yes, master, you are right, master", and bow to your higher knowledge of what everybody needs and wants? Can't you see how absurd is all this?

    All JDO people have done is provide clear justifications to why JDO is how it is, why it differs from what you want it to be, and how you can adapt it to be more like what you want, in case you decide to adopt it. You call this being ignorant? It would be ignorance if they just said yes blindly to each and every criticizm, without proper justification and analisis. I am not saying your criticizms are invalid or not properly justified, just that JDO people have responded to each of them with valid and justified answers. It would be ignorant to blindly dismiss their answers, wouldn't it?

    If your product has such a restricted niche as your post pointed us, or your end users have such a restrictive way of working with object persistence (it must be YOUR way, or no way at all!), then indeed it will be very hard for ANY standard be applied to it. So again, your "fight" against JDO is useless.

    Every standard devised by a community/market/industry is full of compromises in order to satisfy all involved parties. It can't be something tailor made for one specific user/vendor/area, or it wouldn't be a standard in the first place. It must cater for all involved parties in a way that is good enough for everyone. It won't (can't) be the best for everyone, as we have seen from your criticizms, but as a compromise, it is as far as everyone agrees to go in order to have something working in common agreement. Some people, like you, may feel these compromises are too high, others will accept them and rather reap the benefits of having some kind of standard (even if a not perfect one), instead of none at all, and deal with imperfections by extending or improving such standards. Killing these "not good enough" (for you) standards won't help at all, instead will just make us move backwards.

    Carl, I am sure DB4O is a wonderful product. But seeing people who doesn't agree with you as your enemies will rather take them away from your nice tool.

    Regards,
    Henrique Steckelberg
  139. Do I make sense?

    Yes, Carl, you do. Thanks for the discussion. And although I suspected that Hibernate might support a QOM I did not know for certain and I appreciate your posting the URL earlier.

    JDO expects that a managed object would have one persistence manager. The persistence manager is responsible for managing the object's in-memory and in-database states to keep them in synchronization with each other. When you talk about low-level replication of the same object between different databases (albeit of identical structure) I think you're talking about something that would be outside the sweet-spot for JDO.

    JDO expressly abstracts users from the need to invoke a "save" operation. All users have to do is commit a transaction within which the field values of one or more were objects were altered. If JDO exposed a store() method then users would become confused as to when it could/should/must be called. For this reason JDO is unlikely ever to do so.

    A Query Object Model could be implemented by a JDO implementation (most have them underneath the query parser anyway). There is no requirement for a QOM to deliver string-based queries that the query parser would then re-parse. Invocation of a QOM is not standardized by JDO, so the vendor would be free to do what it liked with the results. Presumably the QOM implementation would be the same structure as that produced by the implementation's query parser, and could be "executed" directly. (Executed in this context probably means translated into the underlying query structure of the database).

    If some JDO vendors implemented QOMs and the community started using them to good advantage, then the JDO expert group would probably consider standardizing the API by which the QOM was constructed by the user to aid portability. Of course, perhaps by then another standard for QOM would exist which we could merely reference.

    However, I'm not aware of any JDO vendors which have done this yet, and I am not aware of substantial demand from developers which is likely to lead to it happening. It is, however, quite feasible and could be very efficiently implemented.

    Kind regards, Robin.
  140. Presumably the QOM implementation would be the same structure as that produced by the implementation's query parser, and could be "executed" directly. (Executed in this context probably means translated into the underlying query structure of the database).

    Quite right. Any decent JDO has a Query Object Model underneath its JDOQL parser. JDOQL is there to make it even EASIER than using the QOM. If there was customer demand to expose the QOM, it could be easily done. To harp on QOM vs. JDOQL as some sort of serious differentiator is absurd.

    Someone on this thread also said, "anyone who uses JDOQL came away not liking it" or something like that. What bunk. I mean, JDOQL is so familiar. The BNF basically is a subset of the BNF for Java. So if you didn't like JDOQL, I guess you really don't like the Java language a whole lot.

    OK, so let's find all the customers who have referred another customer whose account balance greater than 10,000 bucks. The JDOQL filter expression is:

    customers.contains(CUSTOMER) && CUSTOMER.referrals.contains(REFERRAL) &&
    REFERRAL.accountBal > 10000.0

    it's a Java boolean expression!

    Which the JDO driver translates to:

    SELECT CUSTOMER.* FROM CUSTOMER, CUSTOMER AS ALIAS0 WHERE CUSTOMER.PK = CUST_REF_JOIN.FK_TO_REFERRER AND CUST_REF_JOIN.FK_TO_REFERRAL = ALIAS0.PK AND ALIAS0.ACCOUNT_BAL > 10000.0;

    Personally I prefer the JDOQL. Just my preference. When you get into supporting enheritence hierarchies (you know, OO programming), JDOQL really makes it easy since the JDO driver can form some very sophisticated UNION queries to simultaneously retrieve all subclasses of Customer in a single query. Basicaly, with JDO, the use of OO programming with a relational database becomes so easy that you take it for granted, which is the way it should be, and which is the reason that Entity Beans never made it easy.

    -geoff
  141. Carl --

    I feel like now we're settling down into a more rational debate. I'll try to address some of your concerns:
    What would you propose to your own userbase as the "standard" to program against? Your own query API addon or the default JDO interface that would allow users to change to another product?

    We like to talk about vendors of spec implementations competing on ease of use, performance, tooling, etc, but the reality is that they also compete on features that go beyond the standard. This would be a feature you would offer that would go beyond the standard, and that your customers could choose to use if its benefit outweighed making part of their code non-portable. Considering that currently *all* of their db4o code is non-portable (please correct me if I'm wrong on that), they'd still be in a better position than they are now.

    If the feature turned out to be very popular, you can bet that other vendors would start offering a similar feature, and that in the next major revision of JDO all these vendors would push for standardization, because that is typically what customers want. That is what occurred with virtually all of the new features in JDO 2: customers wanted a feature, so vendors implemented it, then pushed for standardization, and now it has become part of the spec.
    (Reason 2) Technically you would introduce additional steps to the querying process:(1) The user constructs a tree representation of the query.(2) This produces JDO strings.

    No, you could bypass strings entirely. There are PM.newQuery() method forms that take in an Object as the query representation rather than a String. This Object could be a QueryNode or whatever the nodes in your tree are called, generated from your own query-by-API classes, and you could return a Query that cannot be mutated further (kind of like SQL queries in the spec now).
    I am talking about the JDO spec backing away from the previous filter criteria API to supply SQL syntax instead, with the small addon of providing built-in parameter passing and with domains instead of tables. This is SQL, nothing else, and it does not solve the problem of incompatibilities between SQL dialects.
    I'm sorry, but here you're completely wrong. JDO 2 has introduced two totally separate things:
    1. The ability to execute pure SQL queries. This is part of JDOR, the subset of the JDO spec for implementations on relational databases. This allows users to use DBA-supplied query strings, to use advanced database-specific features, and to go beyond the object model if they want.
    2. A single-string representation of JDOQL. This is not SQL. If you read the spec, you see that this is exactly like the JDOQL of JDO 1, but with tokens to combine the result string, filter string, ordering string, grouping string, etc. We chose SQL-like tokens because these are what many developers are familiar with, and they make sense even in the non-relational world. But just because something starts with "select" and uses clauses like "order by" and "group by" does not make it SQL! The syntax of each clause is still entirely Java-based. And by the way, this ability to represent an entire JDOQL query in one string was driven by user requests.
    My app will not be portable to some implementations if I rely on not having to use enhancement, right?

    How can an app rely on using or not using enhancement? What runtime behavior of the app changes? Enhancement is a deploy-time activity, like configuration. Both might change from vendor to vendor. If a developer is concerned about enhancement, they will like your product and other non-enhancement-based products better than ones that use enhancement, and you have a competitive advantage.
    and yet your own supposedly-safe query system uses String field name arguments!
    There is no way around using field or method names today so we can't help using them, althoug we think it is wrong.

    And therefore your query-by-API is only marginally safer than a pure-string based query system, and no better at automatic refactoring. If there were a way to easily represent class fields in a type-safe way (such as the RFC you have proposed), then I would agree that having a safe way to form queries would be a great enhancement to JDO. I imagine all JDO vendors would want to create a standard for safe query creation. Without such a mechanism, though, I don't see a big advantage to query-by-API. Some might prefer it, but some might not. It is very extreme to call JDO flawed because it chose one system or the other, especially when JDO 2 mainly just listened to its userbase when choosing what direction to go. Plus, as I've said, you can always offer query-by-API in your own implementation.
    (1) String parsing, like it is necessary for JDO queries, is not an option for us.

    I don't think parsing is as resource-intensive as you think, and most good implementations maintain a cache of parsed trees. Still, this is a valid concern. Perhaps for embedded users you would recommend the use of your own query-building system, or the use of named queries (new in JDO 2; the ability to define a query in metadata) which you could pre-process at deploy time to create a more efficient internal representation. As I've said before, even in the former non-portable solution, your customers' code will still be more portable than it is now, and there is a good chance of standardization in the future if it is actually a popular feature.
    (2) We also expect our object database to be frequently used in replication setups. Objects will need to be replicated, copied and moved between databases, they may even have to exist in two databases at the same time. This is not possible with JDO, because objects keep a reference to their PersistenceManager. As a workaround Robin Roos suggests detach() using fetchgroups, but really that seems to much of hassle for our developers. (3) We would also like our users to have full control, what they store and update when. They need to be able to use our engine in non-transparent mode, with explicit calls to our #store() method.

    Again, these would be value-add features you would supply to your embedded users. Some people who've never implemented a spec seem to have the impression that they're forbidden from innovating beyond it. That is completely false. No spec can meet the needs of all users, so vendors step in to do so with their own features. If these features become popular, they may eventually get standardized. If not, the vendor retains a competitive advantage over other vendors that don't offer the features. The vendor still wins because in addition to users that need his proprietary features, by implementing the spec he has opened the door to tons of users who want the portability a spec entails (or who prefer the spec's way to his proprietary way -- most users, for example, don't want to have to call store() for dirty objects). The users win because the ones that need proprietary features get them, and all users get more portability than they had before (even the ones using the proprietary stuff).
    However it would not make sense for us to supply a JDO implementation on top of our engine ourselves. We would discredit our own API and we would distract our users from using what we think is the correct interface of our product.

    I guess we have a difference of opinion here. I like to let the customer decide what interface he likes, and to let the customer balance portability against the value-add of certain features. That is why SolarMetric has committed to supporting JSR 220 in addition to JDO 2 -- we believe in customer choice. I think maybe if you trusted your customers a little more to make good decisions based on their needs, you might be surprised at the results.

    p.s. I see that as I wrote this, Robin has already made some of my points. Sorry for the duplication.
  142. This would be a bad idea for two reasons so I am not surprised that it hasn't been done by vendors:(Reason 1) What would you propose to your own userbase as the "standard" to program against? Your own query API addon or the default JDO interface that would allow users to change to another product? Obviously you would worry your users every decision they have to take.(Reason 2) Technically you would introduce additional steps to the querying process:(1) The user constructs a tree representation of the query.(2) This produces JDO strings.(3) These strings are parsed to produce a tree again.(4) The query is run from there.There is no benefit at all to offer (1) and (2) if you provide access to the much directer and faster level (3) directly.

    I hope ideas from this research project can help to solve your problem http://www.ispras.ru/~gsql/prelim.txt
  143. Today is the last day of voting by the Executive. The results should be made available late tomorrow one the JCP site.
  144. Last night JDO 2.0 passed the Reconsideration Ballot, with no votes against and 3 Abstains (IBM, Oracle and JBoss).

    http://www.jcp.org/en/jsr/results?id=3078

    Congratulations!!!!!!!!!
  145. Last night JDO 2.0 passed the Reconsideration Ballot, with no votes against and 3 Abstains (IBM, Oracle and JBoss).http://www.jcp.org/en/jsr/results?id=3078Congratulations!!!!!!!!!

    Indeed. Well done to all who have worked hard for this. JDO is far from dead (as some have suggested) it is thriving, and this vote indicates it's importance.