Article:		Flawed JDO Points the Way to the "Objectbase"
Subject:		Apples to Apples?
Date:		2002-04-25 22:13:44
From:		tomdavies
This is an apples to apples comparison of JDO and oracles user defined types via JDBC? I don't think so. One of the important things which JDO gives you is the ability to map relationships between relational tables to relationships between object instances in a natural and transparent way, and to give you 'navigational' access to your data via lazy loading. So after you find your root object, which needs explicit use of JDO, you can simply access members which refer to other persistent objects (including collections of persistent objects) in exactly the same way you would if no persistence was involved. The author of this article has found a way to use the *non-portable* UDTs of Oracle to modestly improve the use of JDBC, but in no way is this a general ORM solution with the scope of JDO. Tom

Showing messages 1 through 5 of 5.

• Apples to Apples?
  2002-04-26 05:43:44  Donald Bales | [View]
  
  
  First, UDTs (Oracle or not) are portable because they are part of the SQL:1999 standard which has been implemented by vendors other than Oracle. Second, the use of Java is no more portable that the use of Oracle. Both are portable only because implementations of the core software, the DBMS for Oracle and JVM for Java are provided for most operating systems. So there's nothing *non-portable* about UDTs of Oracle. Third, the lack of the ability to do navigational access only exists in the weakness of the SQLData interface. Oracle's ORAData interface provides this kind of capability.
  
  Most importantly though, you missed my point altogether. You seem happy to continue to use and object-oriented programming language to build software and to use relational technology to store data. That means you're not using the fundamental strengths of object-orientation to place both data and behavior together in a persistence layer where it is accessible to all programming languages. In effect, you're using a *non-portable* Java only solution to the business problems you're solving with the software you're writing. Continuing to use relational technology when mature object-relational technology exists is a disservice to the customers for which we are writing software.
• Apples to Apples?
  2002-04-29 14:35:18  perrin [View]
  
  
  How can you store the behavior in the persistence layer? Writing it in PL/SQL? Using some kind of proprietary Oracle stored procedures in Java? The example in the article does not seem to be storing any behavior, just the current object state.
• Yes, Apples to Apples?
  2002-04-30 10:43:53  Donald Bales | [View]
  
  
  In the case of using Oracle as the persistence layer for SQL:1999 UDTs, behavior can be implemented as "stored procedures" that are part of the UDT written in Oracle's PL/SQL or written in Java. I did not show an example of this in the article because I was trying to limit the functionality as in the program that used JDO in the previous article by Dion Almaer. I do show an example using PL/SQL in my book and also show how to use Java.
• Apples to Apples?
  2002-04-26 18:56:39  Jonathan Gennick | [View]
  
  
  <blockquote>
  In effect, you're using a *non-portable* Java only solution to the business problems you're solving with the software you're writing.
  </blockquote>
  
  Ok, I have a question. If I'm using JDO, what happens when I need to access my objects from another language, say C++? With a UDT, the object definition is stored in the database where it is accessible from any language. Isn't that a good thing?
• Portability?
  2002-04-30 16:36:58  Donald Bales | [View]
  
  
  Entity behavior that exists only in Java classes is not accessible to anything but Java. So it follows that using JDO against a relational database limits the accessibility of behavior to Java programs only.
  
  My assertion is that having entity behavior exist in the objectbase will make it accessible to all languages that can access the objectbase. For the most part, I believe this is an unpopular idea because it is not a Java only solution. Instead it's a Java and SQL solution. SQL's non-procedural nature is its strength. If an objectbase existed where the definition language and access language was strictly implemented in Java, then many Java programmer's would be very happy. But that technology would be stricly procedural and lack the power of SQL.