openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste BRIAUD -- Novlog <>
Subject Re: Why OpenJPA rocks. was: Custom proxy : idea review needed
Date Wed, 05 Aug 2009 23:12:27 GMT

On Aug 6, 2009, at 00:16 , Pinaki Poddar wrote:

> Hi,
>  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.
Yes I fully agree.
> 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
> r.
This is exactly that !

> 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
> -----
> Pinaki
> -- 
> View this message in context:
> Sent from the OpenJPA Users mailing list archive at

View raw message