Article:		Flawed JDO Points the Way to the "Objectbase"
Subject:		JDO can give us more than just JavaBean functionality
Date:		2002-04-26 06:00:59
From:		balesd
Response to: JDO can give us more than just JavaBean functionality
Caching can be problematic. I see no problem caching database connections as long as I can hang onto one long enough to support a transaction and that functionality seems to work. This capability already exists in JDBC. But the caching of data is better performed programmatically if it is non-volatile and in most cases should not be done at all if the data is volatile. Tools don't really push data mapping out of code, instead the entire concept of declaratively mapping relationships between variables in a class to columns in a relational database increase the possibility of misconstruing the purpose of a data attribute, and allow multiple implementations of a mapping to use it for varying purposes. At least if you define a class in an object base you know that it is what it says it is. There's no mapping involved. But most disappointing to me is that you miss the point. If you use JDO with a relational database, your object model exists only in your executable program, not in the persistence layer. Using JDO is a Java only solution. Don't get me wrong, I believe Java is by far the best implementation of an object-oriented programming language to date, but my experience has shown me that the whatever is stored in the persistence layer far out lives the language that put it there. Isn't it time we started saving our behavior with our data? And, by doing so moving our problem domain object model into our persistence layer? Isn't that object-oriented development?

Showing messages 1 through 4 of 4.

• Is an ORDBMS not just another persistence store for JDO?
  2002-05-01 01:43:57  fontaineb [View]
  
  
  JDO technology is not tied to relational databases. Nothing prevents the JDO implementation to use the objectbase approach, as far as the JDO contract is respected. A vendor could even provide tools that generate the database objects definitions. Do you see any "contradiction" between the JDO and objectbase techniques that would prevent objectbase to be used as the basis of a JDO implementation?
• An ORDBMS is not just another persistence store for JDO
  2002-05-01 20:11:00  Donald Bales | [View]
  
  
  JDO has no means of supporting methods calls for UDTs. So the use of JDO would mean the objectbase would be nothing more that a UDT database.
• An ORDBMS is not just another persistence store for JDO
  2002-06-02 23:38:22  tomdavies [View]
  
  
  But JDO associates a Java class name with each instance stored in the database, so effectively it is defining method calls on UDTs. It would be possible to have a JDO implementation which serialized class files to the DB at the time they were enhanced and used a custom class loader to load the class as the data was retrieved.
  
  Tom

• JDO can give us more than just JavaBean functionality
  2002-04-26 14:31:13  Dion Almaer | [View]
  
  
  <quote>
  Caching can be problematic
  </quote>
  
  That is definately true, however, it can be a saviour. How often is the DB the bottleneck on large enterprise projects? I have been on many, where distributed caches have saved the day, giving fantastic performance, and allowing many more clients. Many web sites are heavy on reads. On TheServerSide.Com we make use of that fact with a read only cache of entity data, so we rarely even GO to the database (that is why the site is relatively fast!)
  
  There is a LOT more to caching that caching db connections, which can be done in both JDO and JDBC of course. Ideally I don't want to even talk to a db unless I have too.
  
  <quote>
  Tools don't really push data mapping out of code, ...
  </quote>
  
  IMO, This abstraction can be a good thing. There are times where I just want to write my object, happen to make it persistent, and don't want to worry about the way the table looks. This allows me to use simple SQL for cheasy databases, but use Stored Procs on others, and to be able to change that without changing the code!
  
  <quote>
  ... you use JDO with a relational database, your object model exists only in your executable program, not in the persistence layer
  </quote>
  
  How is this different between the two?
  In general there are a couple of choices:
  
  1. Store an actual object in a database
  - tied to the language that the object is in
  - hard to access state within the db
  2. Store state of object in a database and have something map between the class and the db itself
  - now anyone can query the state
  
  JDO puts behaviour in the objects, and the state are mapped. This IS OO right? We can think of things in JDO as "I want this object persistent" and make it happen. When we need an object we get back the object with its state... and behind the scenes the data is managed for us by the PersistenceManager
  
  I don't think JDO > JDBC, it is just another technology that can be used. Everything has pro's and con's, and business situations dictate a fair amount (e.g. "I can do everything in Java", "I know that I will be using Oracle", etc).
  SQL is great, but in my experience, although a lot is "standard" there are always quirks that each vendor puts in there (like anything else), so it isn't easy to jump from one db to another. I also don't think that people DO jump between databases a lot. The best part of standards like JDBC are because I can *learn* one API, and when I move to another project that does use another db then I know the API to talk to it... and now I just need to learn the quirks (unless I just use a subset of things of course). It would be nice if sequences/identities/etc would be standardized :)
  
  Cheers, and good article / book.
  
  Dion