Re: [Pride-users] Java Persistence API (JPA)

[Anders P. <and...@op...>]

My intention are unclear, but something like this... (people get strange 
ideas)

1) I'd like to do a (my own) JPA implementaion with PriDE as a building 
block. Using PriDE I've had to write code for caching, relationship 
management and other things.  I'm thinking that maybe I'm already well 
on my way to JPA compliance.

2) I don't necessarily need full JPA compliance. PriDE (with my 
extensions) does not need to be fully JPA compliant (a drop in 
replacement for any other JPA implementation), but I should be able to 
replace "my code" with some/any other JPA implementation.

3) JPA users will need an entity bean generator - PriDE already has one 
(ant task and eclipse plugin). Adding support for JPA annotations can't 
be too much work. If I (or someone else) would like to try what I 
mentioned above having a PriDE tools that generates JPA compliant entity 
beans would help. Perhaps you can see supplying a JPA entity bean 
generator as marketing for PriDE.

/Anders

Jan Lessner wrote:
> Hi Anders
> I'm not shure what your intention is when asking for JPA compliance in 
> PriDE. The toolkit follows some general design rules which are 
> fundamentally different to what the mainstream of Java O/R mapping 
> propagates to be state of the art. JPA perfectly represents that 
> mainstream and therefore can easily be adopted by the famous toolkits 
> like e.g. Hibernate or OJB. PriDE must be seen as an alternative, not 
> only concerning the implementation of a particular standard API but as 
> an alternative *approach* for O/R mapping. The approach is based on 
> the design principles which are explained in
>
>    http://pride.sourceforge.net/PriDE-Inside.html
>
> and which contradict to what is required for JPA compliance. The most 
> important difference is that fact, that PriDE does not manage any 
> persistence objects but treats everything as a pure value object. This 
> is the key for using SQL as query language and it implies that there 
> is no support for transparent relationship management and that load 
> and stire operations must be performed explicitely. Changing these 
> design principles would mean to totally redesign PriDE and loose it's 
> central uniqueness: simplicity. You won't find any other O/R mapping 
> toolkit which is so small and easy to maintain and to adapt to 
> personal needs like PriDE. PriDE was developed for teams with a 
> vertical organization which requires every developer to understand 
> (and potentially debug) in a few hours how the persistence manager 
> works. So you see that it is a matter of philosophy why PriDE doesn't 
> follow the JPA standard.
> It is one of the most important advantages of the Java world: knowing 
> to have alternatives :-)
>
> Regards,
> Jan
>
>
>
> Anders Peterson wrote:
>
>> Hi,
>>
>> Are there any plans to make PriDE JPA compatible?
>>
>> I know the idea behind PriDE is not to do all that full JPA 
>> compliance would require, but is it possible that the parts that 
>> PriDE actually does do are made JPA compatible?
>>
>> Could for instance the eclipse plugin and ant tasks generate beans 
>> with all the correct annotations?
>>
>> PriDE leaves you to design and implement some of the more advanced 
>> features. I'm interested in trying to that in a JPA compatible way. 
>> It would help me if the generated beans have the annotations.
>>
>> /Anders
>>  
>>
>


-- 
http://ojalgo.org/

Mathematics, Linear Algebra and Optimisation with Java