openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: Why OpenJPA rocks. was: Custom proxy : idea review needed
Date Wed, 05 Aug 2009 22:16:53 GMT

  I have not come across vertical and horizontal analogy w.r.t. fetch plan -
and it did provide a neat imagery. But this analogy still refers to a 'boxy'
or tabular world view popularized (or monopolized) by RDBMS. 
If one thinks 'out of the box', then 
      a) a query for objects select a list of 'root nodes' {R:r}
and b) the query fetches a graph rooted in each node r. 
And c) fetch plans are a specification to define a sub-graph on closure of

For recursive parent-child relationship, for example, one can specify a
Fetch Plan to traverse the child-to-parent a fixed number of times -- a
notion neither supported in SQL nor in JPA based FETCH JOIN.

Jean-Baptiste BRIAUD -- Novlog wrote:
> Any comments on that vision ?
> On Aug 5, 2009, at 16:33 , Jean-Baptiste BRIAUD -- Novlog wrote:
>> The need is simple : get trees of partially valuated business object  
>> instances from the "big graph" of possible linked business classes.
>> The fact came from old SQooL (a bad IT joke from old school and old  
>> SQL) :
>> 1. only get back from DB what you need.
>> 2. the other thing is to try to make as few trip to the DB as  
>> possible. One request is better than several.
>> DB will optimized if the request look like complex.
>> In other words, let the DB optimize for you, as much as possible.
>> So, I'm in Java, I want instances of my business classes but with  
>> only attributes I need (rule 1).
>> That attributes that had to be taken or left from the DB can be  
>> @Basic one or any other relational one like @ManyToOne, @OneToOne, ...
>> I also want to express that in one request ideally (point 2).
>> I let the Java framework optimize for me and send as few SQL request  
>> as possible.
>> Basically, there is 2 "filters" to distinguish :
>> * vertical one that can filter several "lines" from the million in  
>> the table : this is the WHERE clause
>> * horizontal one that can bring back only certain column : this is  
>> the SELECT clause
>> both are usefull.
>> Vertical one are well taken into account by all the frameworks I had  
>> to use.
>> Horizontal one had been poorly taken into account by other  
>> frameworks I had to use.
>> I can get back with some instances (vertical filter) but with all  
>> attributes (bad horizontal filter).
>> Or I can have both working but the result is an array of hash tables  
>> and I need instances of my business classes.
>> This is really bad since that hash map's keys are not the attribute  
>> (field) name but the position in the SELECT clause !
>> Meta information is just lost in translation and nobody care :-)
>> Some framework are able to handle poorly (better than not handling  
>> at all) horizontal filtering via eager or lazy loading but this only  
>> concern relational attributes excluding @Basic one and also, most of  
>> the time this can't be set dynamicaly and you have to provide as a  
>> developper specific constructor of your business class.
>> All that horizontal filtaring has to be set statically via  
>> annotation or more painfully via XML but not dynamically.
>> At the end, it is a lot of work for the developper for not having  
>> real horizontal filter.
>> As a conclusion, and as far as I know, OpenJPA was the only one able  
>> to give me back some (efficient vertical filter) instances of my  
>> business classes partially valuated depending on my needs (efficient  
>> horizontal filter) both filters can be specified entirely  
>> dynamically if I want but it is also statically via annotation.
>> This had been possible with only one request.
>> Without any reference to an old OO DB, OpenJPA is a precious  
>> gemstone !
>> On Aug 5, 2009, at 15:36 , Pinaki Poddar wrote:
>>> Hi,
>>>> I can tell OpenJPA rocks, what I did had been tested impossible to  
>>>> do with
>>>> other frameworks.
>>> Good to know that you found OpenJPA useful.
>>> Will you please elaborate which aspects/features of OpenJPA are  
>>> distinct
>>> from other frameworks in your view?
>>> -----
>>> Pinaki
>>> -- 
>>> View this message in context:
>>> Sent from the OpenJPA Users mailing list archive at

View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message