wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes JDO Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JDO" Watch "JDO" New topic
Author

JDO

priya shankar
Greenhorn

Joined: May 12, 2003
Posts: 21
All,

Could anyone explain, how does JDO differ from other DataAccess Techniques and what are all the advantages of using JDO?.

Does JDO objects live in a container?

Thanks
Priya Shankar
Eric Samson
Greenhorn

Joined: Sep 01, 2004
Posts: 18
Hello

JDO objects can run in a managed environment (typically a container with in an app server) or they can run in a non-managed environment (J2SE, client-server, batch process, Web Server, PDA...).
That's why JDO is nice, it is database agnostic and architecture independent.

Hope this helps.

Best Regards,
Eric Samson
Greenhorn

Joined: Sep 01, 2004
Posts: 18
besides this JDO 2 provides:


* a complete standard for O/R mapping
* full support of Java models including interfaces, collections, maps, arrays and inheritance
* navigation between object in pure Java (no specific API)
* manipulation of objects in pure Java
* transaction API
* a rich query language
* a way to work on disconnected graphs through Attach/Detach
* portability of persistence layers (at least 30 JDO implementations available today)

Best Regards,
priya shankar
Greenhorn

Joined: May 12, 2003
Posts: 21
Thanks Ericson.

I read in one article that Entity bean diesn't support primary key generation but JDO does.

How does JDO support automatic primary key generation?.Why CMP doesnot?.

Thanks
Priya Shankar
Eric Samson
Greenhorn

Joined: Sep 01, 2004
Posts: 18
JDO supports automatic primary key generation.
The standard defines Datastore IDs that are IDs generated and managed by the JDO implementation. These ID are invisble in the Java class, so there is nothing to do in the Java application.

JDO also supports Application ID, where ID are managed either by the application, the programmer or the database (sequences, triggers, auto-incr columns...). In that case the attributes part of the PK are visible in the Java class.

Please note that best JDO implementations like LiDO supports composite PKs and PKs containing FKs.

Best Regards, Eric Samson.
Erik Bengtson
Ranch Hand

Joined: Dec 06, 2003
Posts: 90
Priya,

The EJB 2 specification says nothing about primary key generation, but most of application servers support it.

In the end what really matters is the set of features supported by the standard, and JDO has a rich set of feature since version 1, including being datastore agnostic and with many implementations like Lido that supports XML, File and relational datastore, object relational concepts like identifying relationships, autoincrement columns, sequences and others. In JDO 2, non standard features for object relational mapping are going to be standarized as many other user requested features are to included like aggregated queries, refinement of callbacks, detach/attach, etc.

I'm confident that today JDO is the best choice within the existing datastore access mechanisms.

Regards,
Pj Murray
Ranch Hand

Joined: Sep 24, 2004
Posts: 194
Before choosing to go ahead with JDO, you should read this recent open letter on the Sun Web site:

http://java.sun.com/j2ee/letter/persistence.html

Sun is aiming for a single persistence API that will be specified through EJB 3 (JSR - 220).

Sun's plans call for "maintenance" of the JDO spec.

The JDO experts are joining in this effort - and will fully participate in JSR 220.



PJ Murray
CodeFutures - Java Code Generation
http://www.codefutures.com
Eric Samson
Greenhorn

Joined: Sep 01, 2004
Posts: 18
Hello PJ

In october Sun decided to clean the situation regarding the standards for persistence.
It has been decided that some experts (3 vendors + 3 independent) from the JDO expert group will join the EJB 3 expert group (it has been done in the meanwhile).
The goal is to create a future common standard for O/R mapping (the name still has to be defined) that could be used by future JDO and EJB releases.
Also what is important is to maintain a good pluggability level in the EJB server so that anybody can choose the best persistence implementation.

JDO will certainly go on. As SDO and EJB will.

It is very important to compare products rather than standards.
Each product implement a vision and has a core technology that is independent from standards, then they implement a compiance layer with one or multiple standards.

Hope this helps.

Best Regards, Eric.
kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
HI All
Yes JDO is really nice and simple,faster compared to Entity beans.
You can check out www.ratings360.com which is developed totally on JDO using JPOX and Spring frameworks.
Thanks
kundan


SCJP1.4,SCBCD,SCEA,CNA
Failures are practice shoots for success.
Thomas Whitmore
Ranch Hand

Joined: Aug 05, 2004
Posts: 33
Hi Priya,

JDO is the most modern & popular standard for Java data access & persistent storage. Basically, it handles the chores of database access and mapping so you can concentrate on requirements and using your object model.

This is the most natural and productive way to develop with Java or OO languages. Previous approaches such as JDBC and BMP have had excessive overheads due to the focus on coding data access rather than actual application. JDO also improves over historical CMP approaches in many ways.

Great question about the container! JDO provides management of persistent data on a per-session basis (PersistenceManager). Independent changes eg for separate web clients can be handled separately. JDO handles this simply and correctly, making it clearly visible what should be going on, whereas CMP relies a little too much on 'magic technology' making it much harder to debug what should be going on inside the appserver.

JDO can be run inside or outside the container and can also be used with lightweight web servers eg Tomcat. These lightweight options are often preferred as being much easier for developers to test, debug and deploy business functionality.

Test/ debug cycles can for example be 3 - 5x more productive, with business logic able to be debugged outside the container using simple JUnit tests. Even logic destined for use in a J2EE container, can be debugged separately if implemented with JDO, making the QC cycle a lot easier for developers.

The future JSR-220 standard is a proposed step to merge the benefits of JDO technology onto EJB. Customers have been requesting better EJB facilities for years now and this would be great but ratification of this step would still be a year or more down the road after JDO2.

Hope this helps.


Cheers,
Thomas
www.powermapjdo.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JDO
 
Similar Threads
JDO and transactions
The price of JDO
Welcome David Jordan and Craig Russell to our Book Promotion of the Week
JDO
JPA and JDO