by Rob 02 Nov 01:58
New Query language - departure from JPAQL... why? Partial objects...

The query language for the previous examples uses find, join etc and you will note that is not the same as JPAQL.

- Firstly Ebean hopefully will implement JPAQL in the future ... However, I was keen to develop a base query language that could support partial objects. I am not sure that JPAQL was designed with this in mind. Perhaps the next release of JPAQL will have support for partial objects?

- What are Partial objects?
Objects that only have some of their properties loaded. If a non-loaded property is accessed then that data will be lazy loaded (just like reference objects).

- Why/when are Partial objects important?
For performance reasons basically. If an object has a lot of properties and you do not need them all, then with partial objects you can just load (query) the properties you need (improving the performance of the query).

This gets more important when your objects have more properties and typically when your database has more data.

Often an object goes through states/steps/stages (such as Order new/approved/shipped/invoiced) and properties are specifically used depending on the state of that object.


- Example

find order (id, orderDate)
join customer (name)
join customer.shippingAddress (*)
join details (*)
join details.product (name)

Description:

Find orders (only the id and order date)
Also get the associated customer (name only)
Also get the customer shipping address (all properties)
Also get the order details (all properties)
Also (for each order detail) get the product name.

Note that this returns an Object graph when all the 'normal' entity objects. It is just that some of the properties have not been loaded.


- The resulting SQL query:

SELECT o.id, o.order_date
, cc.id, cc.name
, csa.id, csa.city, csa.cretime, csa.line_1, csa.line_2, csa.region, csa.updtime
, dd.id, dd.cretime, dd.order_qty, dd.ship_qty, dd.updtime, dd.order_id
, dpp.id, dpp.name
FROM or_order o
JOIN or_customer cc ON o.customer_id = cc.id
LEFT OUTER JOIN or_address csa ON cc.shipping_address_id = csa.id
LEFT OUTER JOIN or_order_detail dd ON o.id = dd.order_id
LEFT OUTER JOIN or_product dpp ON dd.product_id = dpp.id
WHERE o.id ?
ORDER BY o.id desc

03 Nov 17:18
by johan

OpenJPA supports fetch groups for this http://openjpa.apache.org/builds/1.0.0/apache-openjpa-1.0.0/docs/manual/ref_guide_fetch.html. Do you have anything like this in mind too?

04 Nov 10:44
by Rob

Thanks for the link. Yes an interesting feature.

To me this really looks to solve the same problem in a different way, and perhaps openJPA was unable to talk the JPA group into having the query language evolve? (I thought Toplink had a similar feature?).

Definitely need to look at this more, and see what JPA 2 does in this regard.

Create a New Topic

Title:
Body:
 
Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements
woResponse