Andres Testi has posted "An EJB3 Implicit Query proposal," in which he suggests an annotation that will gather data for a field via a query. This would eliminate the need for running a subquery or a join, or writing a method in a DAO to set the field's value. For example, he posts the following code to get a Salesman's salary from a database:@ImplicitQuery( name="Salesman.calculateSalary", parameter="salesman" ) private Long salary;As Mr. Testi says:

Imagine that a salesman take several salary advances, then we want to known which salary advance is greatest than than salesman's sales value sum. In the current EJB3 specification, we must work as follows:SELECT s.salaryAdvance FROM Salesman s WHERE s = :salesman AND s.salaryAdvance.value > ALL( SELECT SUM(sale.value) FROM Sale sale WHERE sale.salesman = :salesman )But with an Implicit Query feature, the query looks as follows:SELECT s.salaryAdvance FROM Salesman s WHERE s = :salesman AND s.salaryAdvance.value > s.salaryThis is a more elegant solution than previous solution.

Another advantage to implicit queries:

Implicit Query simplifies access to queries in the Expression Language, because it's possible to access the query result simply accessing a bean property.

What do you think? Would such a feature be an advance for the EJB3 specification? What issues can you see with it?

I think the URL should be http://andrestesti.blogspot.com/2006/10/implicit-query-proposal-for-ejb3.html

I think the URL should be

http://andrestesti.blogspot.com/2006/10/implicit-query-proposal-for-ejb3.html

Okay, that was wierd beyond understanding - I have NO idea where the URL got corrupted. It's been fixed, and thank you.

EJB3 is getting worst day by day, it is simply a nightmare NO TRANSPARENT at all. Use JDO2.

Actually, as an avid JDO user, I think this proposal has a lot of technical merit. One of the most frequent things I find myself doing in JDO is creating Query objects and executing them to navigate intelligently around the model. The proposal would enable much better encapsulation of this behavior with much more concise code. I like it. I think we need to acknowledge that JPA provides enough capability, especially with proprietary extensions in the implementation to eventually subsume JDO. Given that only Kodo JDO has achieved market success, I think it's safe to say that JPA has captured the momentum.

You are totally wrong. JPA has no way, any kind of momentum. 1rst) Every JPA was actually an Hibernate user. Probes: people still vote for Hibernate. http://www.java.net/pub/pq/122 2nd) JPA and EJB3 was promoted by big Relational Database vendors to ensure Database Lock-In. 3rd) There is no big winner in Java Persistence it is just a very fragmented JPA- EJB3 JDO IBatis OJB Castor JDBC EntityBeans (EJB2) .... and a dozen of (Persistence frameworks)

JPA has no way, any kind of momentum.

That's why folks are writing blogs like this, because they aren't using JPA and EJB3. That's why Sun, Oracle, JBoss, and BEA (at a minimum) have working EJB 3 containers right now, because they like pushing a dead horse. Because they enjoy writing code that nobody wants, and they're all deluded by the same mass-hysteria. No doubt they're all just drones of the Java Enterprise Conspiracy without an independent thought or thinking in the bunch. No doubt the fact that they're using at a mimimum of 3 different EJB 3 ORM implementations comes to play in to this as well. JPA is a minor leap for any of the zillions of Hibernate users if they choose to migrate to the platform. JPA via EJB3 is also an easy migration for anyone running EJB 2 appplications that want to slowly convert over to the new specification, since their EJB 2 code still works in EJB 3 containers they don't have to toss it all out on day one. JPA is also going to be supported by your application server vendors, more one stop shopping. You disregard the marketing power that Sun has with EJB and Java. JPA has several implementations, and its inclusion within EJB 3 will make it magically creep in to organizations which will then have it available, get training on it with all of the other EJB training, from all of the EJB trainers, etc. Just like no matter what nay sayers et al may say about Windows Vista, it WILL have a gazillion installations come next year. JPA is the same way. It's riding along for free with all of the application servers, and it's making them easier to use to boot. JPA is here to stay.

2nd) JPA and EJB3 was promoted by big Relational Database vendors to ensure Database Lock-In.

By this I assume you mean to imply "database lock-in" as "RELATIONAL database lock-in" rather than "Oracle" or "DB2" lock-in. First off, most companies have no problem with database lock-in. It's nice having a central store for ones data, it's nice to have it consistently managed, it's nice to have it consistently accessed. Generic applications may have to worry about DB portablilty, but in-house application writers and designers don't. They embrace their chosen database with zeal and tune and tweak and squeeze everything they can out of it. It takes a GREAT effort to get an organization to change their database, particularly in this day and age where data volumes are getting larger and larger. I won't even start the RDBMS vs ODBMS debate, save that there are zillions of programs that can reasonably connect and do Interesting Things to most any RDBMS on the market, particularly through wonders like ODBC and JDBC, by leveraging the SQL which is Standard Enough, particularly for data query. ODBMS's simply don't have that benefit with no real standard for 3rd party tools to leverage.

3rd) There is no big winner in Java Persistence it is just a very fragmented

Sure there is. JDBC. HUGE winner. Most everything else leverages off of that. But with the JPA being standard in EJB 3, as well as usable in generic java apps, plus the volumes of documentation and books and whatnot that will be provided, JPA will take off from the great start Hibernate gave it and just get bigger as its placed in front of mainstream Java folks. JDO may well be as good or better than JPA, I've never used it. However, JDO never got the traction that JPA through EJB 3 has right now. You don't need a better mousetrap to become popular, you need marketing. EJB 3 and JPA has the marketing and implementations that JDO never had.

You don't need a better mousetrap to become popular, you need marketing. EJB 3 and JPA has the marketing and implementations that JDO never had.

A correction there. JDO has *always* had the implementations.

You are totally wrong.
JPA has no way, any kind of momentum.
1rst) Every JPA was actually an Hibernate user.
Probes: people still vote for Hibernate.
http://www.java.net/pub/pq/122

2nd) JPA and EJB3 was promoted by big Relational Database vendors to ensure Database Lock-In.

3rd) There is no big winner in Java Persistence it is just a very fragmented
JPA- EJB3
JDO
IBatis
OJB
Castor
JDBC
EntityBeans (EJB2)

.... and a dozen of (Persistence frameworks)

JDO was already dead before JPA came out. From a marketing perspective it was a complete utter failure and failed to get traction. When Hibernate came on board, there was a lot of discussion internally at JBoss on whether to go the JDO route or to try and help change EJB from within. We decided to change EJB from within and joined the specification committees. Let's face it. At the time, EJB CMP had at least 2 orders of magnitude of users over JDO and, again, at the time, the JDO 2.0 effort seemed dead in the water and not moving. We look at downloads seriously, and if you look at this graph you'll see that Hibernate downloads spiked at about the same time we started shipping a JPA solution. Sure, this coincided with Hibernate 3, but you'll notice that HIbernate downloads stayed at that level. We attributed a lot of it to aligning Hibernate with a standardization process and showing Hibernate as a standard path for CMP users to migrate. JPA solved a lot of problems in Java EE land. * EJB CMP needed to die. * Java EE needed POJO persistence. Sorry, but, there was no way that vendors would have ever agreed to JDO joining Java EE. Just wasn't going to happen. So get over it. Still, Java EE needed a POJO persistence solution that was usable outside of Java EE and yet tightly integrated. You got it with JPA. Alot of the JDO guys joined the JPA efforts, so you'll probably see good features of JDO creep into JPA. On the flip side, you'll see bad features left out. (You see the same thing with HIbernate, TOplink, etc...) JPA isn't perfect, but has brought a lot of unity to the persistence space as EJB CMP, Toplink, Hibernate, and JDO users have a clear migration path to a standardized platform that the major vendors agree upon. I'm sure you won't agree with anything I've written here, but at least you understand our perspective now. JPA allowed us to expand and grow the Hibernate community and as well as phase out a legacy platform (CMP). Bill

You made it very clear ... From a marketing perspective JPA is great. But, what about the Specification... JDO is by far the best Persistence Specification. Soon or late programmers will need something to reduce the complexity and the impedance mismatch ( http://en.wikipedia.org/wiki/Impedance_mismatch ) between relational databases and object oriented languages and finally forget about SQL. JAVA persistence should be just about OBJECTS . It is only a matter of time, "transparent object persistence" will come, soon or late . And in that world JPA has no future.

JDO is by far the best Persistence Specification.

Whether or not JDO is better is irrelevant. Barely anybody used JDO before JPA came out and barely anybody uses JDO after JPA came out.

Soon or late programmers will need something to reduce the complexity and the impedance mismatch ( http://en.wikipedia.org/wiki/Impedance_mismatch ) between relational databases and object oriented languages and finally forget about SQL.
JAVA persistence should be just about OBJECTS .

It is only a matter of time, "transparent object persistence" will come, soon or late .
And in that world JPA has no future.

IMO, this impedance mismatched can never be resolved until Hard Drives are replaced with super fast solid state memory. I/O is the one true bottleneck and until something new is invented, nobody is going to break the stranglehold RDBM's have on the software industry. Bill Bill

Whether or not JDO is better is irrelevant. Barely anybody used JDO before JPA came out and barely anybody uses JDO after JPA came out.

"Barely anybody" ? Inflammatory terminology from JBoss. Nothing new there then, not like we've never had that. What was MarcFs typical one line answer to posts ... something about sucking something? Move along, nothing to see here. Statistics would actually show that JDO vendors have *significant* customer base, with JDO deployed in many business critical systems in all primary application areas, who are very happy with their persistence solution no matter what stories JBoss, Oracle and IBM perpetuate in their never ending FUD. A recent java.net survey showed significant satisfaction with JDO as a persistence technology even with very little marketing for such technology. Many people value datastore agnosticity. Get over it

You made it very clear ...
From a marketing perspective JPA is great.
But, what about the Specification...
JDO is by far the best Persistence Specification.
Soon or late programmers will need something to reduce the complexity and the impedance mismatch ( http://en.wikipedia.org/wiki/Impedance_mismatch )

Thanks, I'm hoping there wouldn't be too many reading this that didn't know what impedance mismatch is.

between relational databases and object oriented languages and finally forget about SQL.
JAVA persistence should be just about OBJECTS .

It is only a matter of time, "transparent object persistence" will come, soon or late .
And in that world JPA has no future.

I agree with Bill in some sense on this. A drastic change would occur before people start the shift from one conceptual storage model to another. I also think that the relational model has been perfected by the RDBMS vendors and the various other models out there OO and XML are yet to provide true enterprise competition, though XML storage vendors are getting relatively close. Also, don't forget the OO dabases provide semi-transparent persistence model now, it's just that OO dabases are only used in specialized environments and for some reason are not advocated, though there are some relatively good implementation out there. I think another reason OO databases never made it to wide adaption phase, is the lack of standardized OO query language. There were some attempts to do so, but I don't think any really succeeded. Also, standadization goes beyond some so called standards body putting a stamp on a document, it has to be embraced by vendor majority and accepted in developer communities. Ilya

though XML storage vendors are getting relatively close.

Hmmm, doesn't trying force an OO view of the world on an inherently hierarchical model (XML) make the impedence mismatch worse?

Also, standadization goes beyond some so called standards body putting a stamp on a document, it has to be embraced by vendor majority and accepted in developer communities.

Ilya

There's too much legacy out there. Something crazy needs to happen to break the RDBMS stranglehold. BTW, I don't know much about OODBMS's. Can you map existing relational models on top of an OODBMS schema? If not, then maybe that's a place to start... Bill

though XML storage vendors are getting relatively close.

Hmmm, doesn't trying force an OO view of the world on an inherently hierarchical model (XML) make the impedence mismatch worse?

Yes, it does, though one can argue that the impedance mismatch is far less with XML/OO rather than relational/OO models. XML can better represent an OO model with its hierarchical structure, though of course there is a mismatch, specifically when dealing with cyclical associations. The issue is that a lot of data is best represented in a hierarchical format, and though you can represent the same data just as efficiently in OO, due to today’s XML based standards popularity and SOA, a lot of data is already being represented as XML, even if for a short lived period within the transport of it. The argument for XML databases is that since you're already faced with representing the data in XML for SOA based reasons (and no, SOA doesn't have to be XML based, but it most certainly is so today), you don't want to add another level of impedance mismatch OO/RDBMS/XML. I think the focus within the OO community should be on an OO query standard, as some of the ORM vendors have added to their product, though it's non standard, needs more features, and is too closely tied to the relational underlying storage concepts. I think if the community can come together for such, we might eventually resurrect the native OO storage market. Remember, the success of the relational theory lies not necessarily in it's efficiency of storing rectangular data sets, but rather due to the standardization of SQL and it's vendor implementations.

Also, standardization goes beyond some so called standards body putting a stamp on a document, it has to be embraced by vendor majority and accepted in developer communities.

Ilya

There's too much legacy out there. Something crazy needs to happen to break the RDBMS stranglehold. BTW, I don't know much about OODBMS's. Can you map existing relational models on top of an OODBMS schema? If not, then maybe that's a place to start...

Bill

Agree, legacy is the major issue with a transition to another model, though why I think XML can provide a middle ground, since most legacy apps that participate in SOA today, would most likely have to transform the data to XML in one form or another. A good middle ground to an ODBMS might be the object relational model, though it's not completely a native OO storage model, one can argue the transitioning from such a model to a pure OO storage model would be easier in the future. Most relational vendors today offer some OO data type facilities, though of course working with them using SQL and some of it's OO extensions is not very natural. Ilya

I have used both JDO and EJB3. I implement two prototypes of the same application with these APIs. One one hand I have JDO (Versant Open Access- ex JDO genie) and EJB3 (Jboss). First of all, JDO is not only for OO databases. There is mapper (Versant, Kodo, Speedo, ...) to RDBMS. JDO vs EJB3 is consequently not a choice between OODMS and RDBMS. I'm not sure that all the JDO mapping product still exists. My prototype was a J2EE application, with something about 1000 pojos a lot of access to the DB and some complex queries (supported neither by JDOQL nor by EJBQL). My conclusion (true on my prototype ... maybe not for all applications): With JDO - we had a poor langage of query, to have good performance we had to write some SQL query (it is in JDO spec to be able execute query in a langage supported by the DB) - No intgration with EJB3 session bean. - poor integration with J2ee (there is a connector but it is not convenient) - POJO easier to writte: There is no need to take care of the cascade type. - Access to methods that returns all the dirty pojo and old its dirty properties (dirty = needs to be apdate,delete or create in db). - good performance With EJB3: - Nice query langage a lot of native query have been written in EJBQL - Very good integration with EJB3 session bean and MDB and J2EE - We had to take care with cascadeType and where object are persisted. Adding cascadeType=persist to simulate JDO cascade type leads to very poor performance (application not usable). With taking care of the cascade type, it results in most of the case with good performance except in some specifci cases. Flush in JDO impl is much more efficient than in hibernate ( several issues have been open in jboss JIRA). In fact our jdo impl a list of dirty objects, consequently flush is just an update of the DB. With hibernate, flush is slower. It is visible when a lot of objects have been retrieved in the same transactions, before each query flush is performed, the time used to perform the same query will vary due to the flush. In our case one of our service starts by updating a lot of objects in DB and then by performing queries and still updating some pojos. Performing all that jobs in the same query was nice when at the end of the computation a rollback criteria was reached. With taking care with that we have improve the perf of the service but it is still slower than in JDO. Concerning the problem I suppose that it is more a problem of impl than a problem od spec. Once again, recently it looks that a bug as been solve concerning the flush in hibernate. Maybe that solve tis problem ??? None of two spec are perfect. We choose to defintely use EJB3 because this solution had great benefit (integration with J2EE) and that with some precaution, it was possible to writte an application that works fine. An EJB3 with cascade as in JDO will be great.(not a problem of RDBMS or OODMS since JDO mapper have implements efficiently that features on RDBMS).

Soon or late programmers will need something to reduce the complexity and the impedance mismatch ( http://en.wikipedia.org/wiki/Impedance_mismatch ) between relational databases and object oriented languages and finally forget about SQL. JAVA persistence should be just about OBJECTS . << Just to address this comment I think some people will agree and some disagree. I'd say that JPA is Object Relational Mapping (in its nature) and not necessarily suited to people who want Transparent OO Persistence. For me, there are people who see benefit in the Relational part of ORM and those that don't (and take a more OODBMS perspective of transparent persistence). You may be right in that OODBMS and Transparent persistence of Objects eventually takes over from ORM/RDBMS but I equate that to saying you see no benefit in the 'Relational' part of ORM/RDBMS. In other words, are there situations where the 'Relational' model provides a better solution to the OODBMS world? For me the cases of updates/deletes in a stateless environment and Ad Hoc queries are a strength of RDBMS. The strengths of OODBMS such as fast object graph navigation could be better addressed in ORM/RDBMS with things like using physical ROWID's. Perhaps OODBMS and ORM/RDBMS will start to look very similar in the future and we get the best of both worlds.

What this boils down to is a need to make queries against methods in an object. The hard part is how do I express this method. There has been ideas that you should translate java code to sql. This has problems since Java is not made for translating to sql. I like this idéa, because it is something that could be done quite "easily". I think you this idea should be sent to the EJB JCP group.

It's too bad this has turned into yet another flame war between EJB3 and JDO folks. It's not surprising though. Anyways, this is actually an interesting idea. You have an object that has a method whose calculation is best handled by a database. In the typical DAO-minded world, this would mean that the object must the DAO for this calculation, which breaks the OOP principle of encapsulation. Hence this clever little annotation that would allow the object's manager (EntityManager in this case, but whatever) to access the database for the object and make the calculation on behalf of the object, without an explicit use of another object. Very nice. One could imagine this idea being extended for other operations, not just data retrieval. Maybe some types of manual cascading of updates, etc.