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 20:54:11 GMT
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 raw message