This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Object Relational Mapping and the fly likes Lowdown on JDO 2? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Lowdown on JDO 2?" Watch "Lowdown on JDO 2?" New topic
Author

Lowdown on JDO 2?

Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
I have been poking in and out of the JDO community for several months. As a result, I am not in touch with all of the JDO 2 developments. Whats the lowdown on JDO 2? Some vendors have been implementing JDO 2 features. When should we expect the whole enchilada?

Regards,

Joshua
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
I am not quite sure but I have heard some rumours that the JDO 2.0 spec is due in the next few weeks. As for implementations you should check them on site. I guess they will provide you more detailed info about the level of satifiying the new spec.

./pope


blog - InfoQ.com
Robin Roos
author
Greenhorn

Joined: Nov 01, 2004
Posts: 15
Hi Joshua

JDO 2.0 is progressing very well. We are indeed working towards the public review. There have been several incremental drafts under consideration by the group in just the last 5 weeks, and we expect to publish the new draft real soon now.

I had wanted the next draft to go out a month ago, but our wise specifiation lead insisted that the next draft be as close to final as possible, so we're hammering out the details of the last few JDO 2.0 capabilities.

The new draft will showcase the Single-string form of JDOQL, a personal favourite feature, and includes tightened details on deachment and ORM. I'm sure you'll enjoy it.

Are there specific JDO 2.0 features you're keen on?

Kind regards, Robin.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0321123808/ref=jranch-20" target="_blank" rel="nofollow">Java Data Objects</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995

Single-string form of JDOQL, a personal favourite feature


Can you detail the idea behind this pls?

./pope
Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
I am not looking for any feature specifically. I am new to JDO and was trying to minimize the learning curve by learning only one version of the specification. I was hoping that 2.0 would be finalized soon. It sound like it still may be far enough away that I am going to wind up learning the 1.0 spec as well.
Robin Roos
author
Greenhorn

Joined: Nov 01, 2004
Posts: 15
Hi Joshua

We've not broken anything in JDO 1.0, we've merely added new capabilities. It makes sense to read about JDO 1.0 and then refer to more recent documentation for the new bits, e.g. the Kodo manual.

The new bits build on JDO 1.0 to deliver:
- standardized OR mapping metadata
- query aggregation/projection and single-string form
- detachment
etc.

With nothing deprecated from JDO 1.0, everything you learn will be relevant going forward.

Kind regards, Robin.
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
Originally posted by Ali Pope:


Can you detail the idea behind this pls?

./pope


I'm also interested in what is meant by the single-string form of JDOQL.

How is it different and what's the advantage?

Thanks,


<a href="mailto:JBROWN2002@cfl.rr.com" rel="nofollow">JBROWN2002@cfl.rr.com</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Robin what is your knowledge about the level of JDO 2.0 presence into implementation products? Do you have a list of products offering already some of the features in JDO 2.0?

many thanks
./pope
Robin Roos
author
Greenhorn

Joined: Nov 01, 2004
Posts: 15
Hi Everyone

JDO 2.0 introduces a single-string form of JDOQL. The grammar is approximately as shown below:

[select [ [unique] <result> [into <result-class>] ] ]
[from <candidate-class> [exclude subclasses] ]
[where <filter>]
[variables <variable-list> ]
[parameters <parameter-list>]
[imports <import-list>]
[group by <grouping-clause> [having <having-clause>] ]
[order by <ordering-clause>]
[range <from-range> to <to-range>]

There are additional keywords as well, such as "distinct" and "as", but these are part of <result-clause> and don't appear in the grammar above.

Here are some examples of JDOQL queries expressed in their single-string form. I find it more accessible than the programatic representation, but it's still the same language and the semantics are no different between the string and api forms. To better support single-string queries, JDOQL now supports implicitly typed parameters and variables with no formal declaration (although formal declaration remains supported).

We're still refining the grammar, but here are some sample queries for your consideration:


select from com.hr.Employee

select from com.hr.Employee order by salary ascending

select from com.hr.Employee where salary > :sal

select from com.hr.Employee where dept.name == :dep

select from com.hr.Department where emps.contains(emp) & emp.salary > :sal

select from com.hr.Department where :depts.contains(name)

select name from com.hr.Employee dept.name == :deptName

select name, salary, boss AS reportsTo into com.hr.Info from com.hr.Employee where dept.name == :deptName

select avg(salary) from com.hr.Employee where dept.name == :deptName

select avg(salary), sum(salary) from com.hr.Employee where dept.name == :deptName

select avg(salary), sum(salary), dept.name from com.hr.Employee where dept.name == :deptName group by dept.name having count(dept.name) > 1

select unique from com.hr.Employee where name == :empName

select unique salary into java.lang.Float from com.hr.Employee where name == :empName

select into com.hr.EmpWrapper from com.hr.Employee where salary > :sal

select into com.hr.EmpInfo from com.hr.Employee where salary > :sal

select e.name from com.hr.Department where name.startsWith('Research') &&
emps.contains(e)

Kind regards, Robin.
[ November 11, 2004: Message edited by: Robin Roos ]
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
This seems to me very much in the direction of ODMG and/or HQL.

./pope
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
I've also been very pleasantly surprised that a large portion of JDOQL maps well with semantics in OCL (Object Constraint Language), which we have been using in our UML specifications. I'm now in the process of building transformation patterns that map from OCL post conditions to JDOQL semantic code.

I think it might be an interesting exercise seeing if it would be worth the effort to use OCL as a standard language, being as this is a standard included in UML.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
John can you go further on subject. I haven't used much OCL, but for me it seems there is no real/logical connection between a query language based on odmg and ocl (but I might be wrong ).

./pope
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
I'll try an example on the fly, rather than look up one in our current model (I might be able to show more later).

For example: Say we have the following classes - Reservation, Guest, and Address

(If I could attach a class diagram I would, but I will have to describe it)

A Reservation has an association with Guest such that there are 0..n guests for a reservation.

A reservation also has an association of exactly one primary guest (the navigating role to the Guest class is primaryGuest.

A Guest has an association with Address such that there are 0..n addreses for a Guest.

One such OCL business rule is that a reservation must have one and only one primaryGuest (which is enforced with the primaryGuest association), and that the primaryGuest must have at least one address.

Here's that OCL as an invariant:



This doesn't apply to a query, but lets now define a method to find all reservations whose primaryGuest has an address in Florida and has 4 guests or less. To do this I'm going to put a method on Reservation as such:



Then I can pass florida (State.FL as an enumeration) and 4 to the method.

The implementation of this method in JDOQL 2.0 code is this:



There are a number of other functions in JDOQL that map well to OCL:



I'm only touching the surface of investigating this, but I did find that most of the OCL we have written for queries can easily map to JDOQL with a little syntax and semantic change.

[ November 11, 2004: Message edited by: John M Brown ]

[ November 11, 2004: Message edited by: John M Brown ]

[ November 11, 2004: Message edited by: John M Brown ]
[ November 11, 2004: Message edited by: John M Brown ]
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
I see your point (just the way I have imagined). I still belive that OCL would translate in fact into constraints and not in queries (or finder methods as you named it).
However if you found this util for your project, maybe I am wrong .

./pope
Neelan Choksi
Greenhorn

Joined: Feb 06, 2004
Posts: 3
Most people agree that JSR-220 (EJB3) won't be finalized and standardized till 2006. So anyone that claims they can tell you that one product is EJB3 and that another product is not is just trying to grab mindshare. The bottom line is that the persistence portions (let alone the rest of JSR-220) is still in process. Until JSR-220 is further along, no vendor can claim that "it is EJB3".

Call me an idealist but I hope JSR-220 will incorporate the best of Hibernate, Toplink, entity beans, Kodo JDO and the other 20+ JDO products, experts, and, most importantly, end users to develop a strong persistence specification. Each group has something valuable to bring to the table and the Java community will be best served if the JSR-220 expert group listens without bias to all of these opinions.


Neelan Choksi<br />SolarMetric, Inc.<br /> <a href="mailto:neelan@solarmetric.com" rel="nofollow">neelan@solarmetric.com</a>
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
Originally posted by Ali Pope:
I see your point (just the way I have imagined). I still belive that OCL would translate in fact into constraints and not in queries (or finder methods as you named it).
However if you found this util for your project, maybe I am wrong .

./pope


You are absolutely correct in your statement that OCL translates into constraints. All OCL should evaluate to true or false and should be free of side effects. post conditions define the constraint of what should be true after the method is executed. For queries it usually equates to the fact that the result is equal to a subset (or collection) of objects that meet the filter criteria.

We use preconditions and especially post conditions a lot in our models. This information is then passed down in code generation from our MDA tool to give the developer the information needed to know what to implement in the methods. The closer that we can leverage the OCL language though, the less coding work is needed for the methods.

I know this is probably a much more rigorous model than most projects and companies are accustomed to, but along with selecting technologies like JDO and using other patterns, it fits very well with our MDA strategy.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Neelan I agree and I disagree with you . I agree in what regards that claiming at this beginning point to be EJB3 is quite uncommon. But, as you probably know, all those vendors (including SolarMetrics I guess - no offense intended) send their guys to JCP also to have insights in more real time, also to try to suggest technics that come from their experience, so I would expect that some of the declarations are quite true. As you probably know, there were already 2 announcements about EJB3: one from Resin (if i remember well) and one from Hibernate. Even if they have used the EJB3 draft, the truth is not quite so far away .

./pope

PS: I have had a discussion with Gavin on this matter and even if I not fully agree with him I appreciate the effort of some solutions to provide an early preview of what is coming. Having feedback from real users is very important. Deciding what will be the future with closed doors is not imo the way to go. I am defintely appreciating any possible preview about future specs, even if they are incomplete and maybe far away from the final.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
John I was not complaining/questioning about the process your co has behind. I just wanted to understand the idea. While I can see the usage in your examples, imo the rationale behind those principles is different ;-).

just my 2c. best wishes
./pope
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
Ali,
I hope that I was able to explain it well enough to you. I didn't think you were complaining or arguing, but sometimes I may come on strong when I post about the things we are doing that I'm passionate about. I also like to share and investigate other opinions and strategies on these things to so I can lean more. Thanks for giving me the opportunity to share
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Lowdown on JDO 2?