EJB 3.0 and JDO 2.0: Views from both sides

JDO FUD by Abe White

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

1. JDOQL

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

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

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

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

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

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

2. Field Interception

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

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


3. Complexity

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

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

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

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

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

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

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

Conclusions

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

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

EJB 3.0 and JDO 2.0: Views from both sides

But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.

EJB 3.0 and JDO 2.0: Views from both sides

But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.

Ok, it looks very cool. How DBA can tune it ?

The tools should get better

Query Language Tradeoffs?

Query Language Tradeoffs?

My campaign of FUD

My campaign of FUD

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

A Question or Practicality

Query Language Tradeoffs?

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

Query Language Tradeoffs?

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

Don't forget that in 3-4 years from now the computers with Terabytes of RAM will be probably the reality. So content of most of the databases can be fully kept in memory.http://www.prevayler.org/wiki.jsp?topic=BreakthroughsInMemoryTechnologyPermormace tunning: MS SQL server is alredy doing self-tuning and managment of indicies. And you have almost no control over it. It's far away from being perfect but it will improve (like garabe collecting in java did). There is some probability that other RDBMS system will follow this path and most of database tuining will be done automatically.Michal

no technical substance

Query Language Tradeoffs?

Misconception

My campaign of FUD

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

Speak for yourself

The Java world has already adopted Hibernate over JDO, so apparently I am not the only one who thinks JDO is not perfect.

responding to my own post...

My campaign of FUD

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

For the record, you can do this in JDO also. No problem. I don't want to get into a "pissing match" either; I just want to stop the misinformation.

Query Language Tradeoffs?

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

Query Language Tradeoffs?

JDO versus Hibernate versus NewAndCool

ejb.jdo well nothing beat good old jdbc

ejb.jdo well nothing beat good old jdbc

nothing beats good old vanilla jdbc. why do we have to bother will all the ejbql, jdoql crap. just use the good old straightforward jdbc.

Query Language Tradeoffs?

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

Query Language Tradeoffs?

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

Query Language Tradeoffs?

switching DBs with JDO

Query Language Tradeoffs?

Query Language Tradeoffs?

switching DBs with JDO

Query Language Tradeoffs?

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

Of course, JDO uses one Model and why not?

Why do we need to use two models? Do you think it is possible to write something meaningfull without relational model knowlege?

Of course, JDO uses one Model and why not?

Why do we need to use two models? Do you think it is possible to write something meaningfull without relational model knowlege?

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

Query Language Tradeoffs?

How does JDO compensate for (what I would consider) a simple fact of the impedance mismatch between an object and relational model?

Query Language Tradeoffs?

switching DBs with JDO

Although hesitant to join this discussion I do feel that the theme of dispelling misinformation must be continued.OracleAS TopLink provides our customers with database independence. We generate and support the use of standard and native SQL for all of the major relational database vendors. This is public information in our statement of direction on our Oracle Technology Network (OTN) page.Not only do we claim this support but we verify this against all the major vendors and releases. Our enterprise customers are not purely Oracle database or Oracle Application Server. In most cases these large customers must maintain a heterogeneous set of databases and application servers.Cheers,Doug ClarkeProduct Manager, OracleAS TopLink

leveraging the mapping expertise of experts

Query Language Tradeoffs?

leveraging the mapping expertise of experts

One advantage you get with JDO technology is that the JDO companies have true experts into how to most efficiently map object models into relational databases, people like Abe White. To respond to another post, yes I know SQL, I was promoting its use back in the early 1980s and I have used it on a variety of applications since then. But your average Java developer out there is not a SQL expert. And even if they are, they are often under very tight schedule constraints and spending time thinking about how to optimize their SQL is less important than being sure all the functionality of the application is working by the delivery date. With JDO, the optimal mapping strategies have been codified and made mechanical and automated in the JDO tool. Some of you love SQL and want to use SQL. That is fine, you can use SQL and you will not be able to leverage the benefits from defining an object model. But if you are building Java object models and handling their mapping by yourself, you are working in a very inefficient manner. Your facilities are not going to be as sophisticated as the JDO API and for each new class you want to make persistent, you have a lot more work to do. JDO lets you work with Java object models, JDBC lets you work with relational models through the SQL language. For some applications, SQL is an appropriate technology. But for other applications, ones that require the use of object-oriented facilities like encapsulation, inheritance, and polymorphism, JDO lets you base your application on those object models and automates the mapping of those models to the database. And it does so in a manner that also makes your application completely independent of the underlying database. If you use JDBC, you will quickly lock yourself into the SQL dialect of the database you are using. With JDO, the JDO implementation takes care of handling the various SQL dialects.

leveraging the mapping expertise of experts

leveraging the mapping expertise of experts

No one is asking or forcing you to stop doing SQL.I assume you are not doing object models. If you don't care about having an object model, then don't use JDO. If you do want to use object models for your persistent information, then JDO is the JCP standard for doing it in Java.Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.

Query Language Tradeoffs?

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

leveraging the mapping expertise of experts

Misconception

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

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

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

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

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

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

Good question, I'd like to know too

But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.

Ok, it looks very cool. How DBA can tune it ?

leveraging the mapping expertise of experts

Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.

On object models

Good question, I'd like to know too

But rather than take our word for it, let's look at an example:Query q = pm.newQuery (Employee.class);q.setResult ("firstName, lastName, department"); q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");We think it is pretty clear to anyone who knows Java exactly what this query does. It selects the first name, last name, and department object of every employee who is older than 50, not retired, in the marketing department, and who is not working on any projects.

Ok, it looks very cool. How DBA can tune it ?

I don't know hibernate or any of the JDO packages well enough to say how it is handled. On large financial projects, the DBA's tend to lock down the database and developers do not have access to write stored procedures. Many companies require that all queries go through the DBA, so that every single query is tested and profiled. For small projects with less than 10-15 million rows of data, it's probably ok to let the developers just write the queries. But when the database contains 100million+ rows of data, profiling the queries and creating views to optimize read queries is very important.

leveraging the mapping expertise of experts

No one is asking or forcing you to stop doing SQL.I assume you are not doing object models. If you don't care about having an object model, then don't use JDO. If you do want to use object models for your persistent information, then JDO is the JCP standard for doing it in Java.Some of us feel that object models are appropriate for use in enterprise applications. And JDO is being used in enterprise applications.

Yes, my objects are more data structures than objects models. I see code and ideas on forums, blogs and I am sure most of "enterprise" applications are implemented this way : Statefull services like session beans, DAO and DTA/value objects.This is not "Object Model", as I understand JDO PersistenceManager is a set of "procedures" too. Evrything usel and domain model is RDBMS. This discussion helps me understand it, It was very usefull for me and I have no more commens.

How banks implement Queries

On large financial projects, the DBA's tend to lock down the database<snip>

Query Language Tradeoffs?

EJB 3.0 and JDO 2.0: Views from both sides

q.setFilter ("age > 50 && !retired && department.name == 'Marketing' && projects.isEmpty ()"); q.orderBy ("employeeId ascending");

Query Language Tradeoffs?

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

EJB 3.0 and JDO 2.0: Views from both sides

Query Language Tradeoffs?

Query Language Tradeoffs?

Best DAO is... (and ... I don't like what Hibernate did either)

JDO versus Hibernate versus NewAndCool

I would encourage the Hibernate folks and the JDO folks not to fight, but to work both collaboratively and competitively, while not being overwhelmed by egos, to develop the most generally useful technical solution. And understand that we are still a long way from that goal, if we look outside of the individual camp that often colors our perspective, preventing us from recognizing the needs of the larger Java community.

leveraging the mapping expertise of experts

That clears up why you don't understand the beauty of ORM. And it makes me wonder why you are using Java? Why not C/C++. Especially if speed is concern. Why not .Net? It integrates great with the vendor platform giving performance and superior integration on that platform.

Query Language Tradeoffs?

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

Query Language Tradeoffs?

Hi, Abe.Thanks for your list.In my view, the only reason to use one of these frameworks is to get my objects in and out of the database. Every time I've used one (and this includes Entity Beans), I have to jump through hoops to get the concurrency right (or, at least, acceptable--it's almost never optimal), and they always generate SQL that just sucks.Now, if JDO will allow me to do native database locking, and not try to do it on its own (because I don't believe it can do it correctly without either being inefficient, just wrong, or more painful than the native database), then that's cool. I don't want it to "be my database"; I just want it for the brokering.Thanks,--Kevin

leveraging the mapping expertise of experts

You could implement your DAO objects using JDO to do all the mapping work for you automatically. JDO lets you get this part of the task done much faster than coding this yourself. It automates this mapping behavior, and does so in a uniform manner throughout your object model. It also allows you to query relative to that object model. I doubt your handcrafted OR mapping supports queries at the object level. It is extremely rare for an application to undertake that level of sophistication. JDO also automatically tracks your updates, to fields and relationships and then automatically maps these updates back to the database, without a single line of code written by you. JDO is going to be much more productive than you coding this all yourself.When I talk about persistent objects, I am not referring to the JDO PersistenceManager, that is not part of your domain model, that is an interface used to access services of the JDO interface. Yes, every object in an object model has a set of methods, a set of "procedures". I don't know what your statement about that is supposed to mean. You don't persist the PersistenceManager in JDO. JDO can persistent instances of the Java classes that you (or others) have defined. Your Java classes can be very thin with simple getters and setters, or they can have a very rich set of semantics and behavior, it is entirely up to you.

WTF?

Query Language Tradeoffs?

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

Query Language Tradeoffs?

OO vs. RestOfTheWorld debate

This discussion proved it for me, object model on top of relational model is useless. All JDO/EJB advokates say O/R is very good for objects and domain model, but nobody can explain why it I need this object model on top on relational model, I found nothing wrong in relational model, data structures and procedures aka DAO and DTO...

Where is advantage?

OO vs. RestOfTheWorld debate

RTFM if you're looking for answers, give it a try, and join the league of happy OO developers... or not... it's up to you.Sometimes I wonder if we can really convince people that OO thinking is better, since it's a paradigm shift. Anyway, I wonder why people choose Java if they don't intend to adopt object orientation... I really can't see a good reason.My reasons for using OO: mental health and fun. Procedural languages and relational models drive me crazy: lack of clear semantics. Too much complexity to handle for me, I'm not that smart. I enjoy object-oriented thinking. Chris

Query Language Tradeoffs?

there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database

Query Language Tradeoffs?

Hi Kevin

there is quite a bit of difference between effective SQL in one database v. another, and it is very important that you use SQL that works best with your database

If you are using JDO then a lot of this responsibility is passed on to the implementation. Developers can concentrate implementing functionality. In a large application there will be some generated queries that need to be replaced with hand written SQL or a stored procedure. This work can be done by the best SQL people on the team. On the prior-to-JDO projects I have worked on the "SQL gurus" spent a lot of time fixing slow/broken queries written by the average developers.My contention is that using JDO raises the overall quality of the SQL used by the application. The implementation will produce SQL that is at least as good as what the typical developer codes and is always correct (no missing join conditions etc). The SQL gurus can concentrate on making sure that the really important 5% of queries run as fast as possible.CheersDavidplay with JDOQWL

Query Language Tradeoffs?

Query Language Tradeoffs?

EJB 1.0 and EJB 2.0 may now become obsolete. But an investment in JDO will not become obsolete.

Query Language Tradeoffs?

Both EJB3 and JDO2 Will Be Backwards Compatible

So with each major [EJB] release, there is a lot of work to do to migrate to the new release... That is not going to be the case with the JDO 1.0 to JDO 2.0 migration.

Status

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

in J2EE land, KISS is not allowed

EJB 3.0 should learn about Optional Features from JDO

Query Language Tradeoffs?

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

EJB 3.0 should learn about Optional Features from JDO

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

...superseded persistence architectures...

...concept of the optional feature...

Does EJB 3.0 refer to its new persistence capability with the term "transparent persistence" or "POJO persistence"

Query Language Tradeoffs?

Do you think somebody can let me to use my faworite innovation for the real projects?

EJB 3.0 should learn about Optional Features from JDO

Query Language Tradeoffs?

Query Language Tradeoffs?

EJB 3.0 should learn about Optional Features from JDO

So why must a new entrant to your marketplace support and interoperate with [the EJB 2.x API]?

EJB 3.0 should learn about Optional Features from JDO

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

Cannes JDO meeting

EJB 3.0 should learn about Optional Features from JDO

Cannes? Boy, you JDO guys must be loaded. EJB is a no-frills group. ;-)

The Cannes meeting is to coincide with some conference taking place there

EJB 3.0 should learn about Optional Features from JDO

It is designed to make the most common cases really easy. But there are advanced EJB features which people find useful in more specialised situations. For these cases, the people can fall back on the existing 2.x API.

EJB 3.0 should learn about Optional Features from JDO

By the way, Scott, is anyone addressing JAOO in Cannes on EJB 3.0?

Query Language Tradeoffs?

What is obsolete? JDO 1.0? Sorry - not the case. JDO 2.0 merely standardizes some already available features in terms of O/R mapping and Queries. I guess you could say Detachment is the "new" feature, but it's not exactly a fundamentally required concept, and it's already being trialled in production versions prior to standardization.JDO 1.0 is far from obsolete, just don't use the makeTransient() method too much (it's been deprecated). Juozas, just what are you getting at?

Query Language Tradeoffs?

Query Language Tradeoffs?

Query Language Tradeoffs?

Not true

Simple Question