continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: Some continuum-jpa branch updates
Date Fri, 18 Jan 2008 14:18:00 GMT
Hi Rahul,

After few days to look at JPA, I'm sure now it would be good to use it
instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA).
The code is very easy to write and to read with JPA.

About your continuum-jpa branch, I have few remarks:
- I don't think it's good to use directly some OpenJPA APIs. If possible,
I'd prefer to use only standard JPA APIs so we'll can choose later the
implementation we want to use (OpenJPA, TopLink, JPOX...)
- why do you use some Spring code?
- we don't need to store the model encoding (CommonUpdatableModelEntity
class)
- can you explain dateCreated/dateUpdated fields? How are they managed?
- all the model is fectched eagerly and it isn't acceptable for performance
- I'm not sure your Query "pattern" is good. I'd prefer to use named queries
but maybe you have a reason

That's all for the moment.

Emmanuel

On Jan 16, 2008 11:30 PM, Rahul Thakur <rahul.thakur.xdev@gmail.com> wrote:

>
> Just wondering if anyone else got to the changes?
>
>
> Emmanuel Venisse wrote:
> > I don't have the time to look at it these days but I'll do it asap
> > (maybe in few weeks :( )
> >
> > Emmanuel
> >
> > Rahul Thakur a écrit :
> >> Hi All,
> >>
> >> Scribbling some quick notes on some of the toying around I have been
> >> doing with OpenJPA, Generics etc on the continuum-jpa branch[1]:
> >>
> >> 1) Use JPA for persistence
> >> Motivation behind this has been to investigate how this compares to
> >> JPOX/JDO for managing the model - both in terms on performance and
> >> ease of use (Store APIs). Continuum model classes are annotated with
> >> JPA annotations on the branch. However, this needs a review as there
> >> are some elements (for example 'configuration' typed as Map) that I am
> >> not sure yet how to persist yet. The provider used is OpenJPA [2].
> >>
> >> 2) Refactorings to Store interface
> >> Main motivation has been to keep the core Store interface lean and
> >> mean (read extensible). The Store interface[3] now has 4 methods:
> >> lookup()
> >> save()
> >> delete()
> >> query()
> >>
> >> The lookup(), save() and delete() act on single model Entity, while
> >> query() will filter and obtain matching Entities from the underlying
> >> database based on the Query specified. Query implementations control
> >> how a resulting JPQL gets constructed and which matching entities get
> >> pulled, and can be easily extended.
> >>
> >> To preserve compatibility with the existing Store interface, we can
> >> mimick the existing ContinuumStore interface operations by having a
> >> facade that can prepare requisite queries and delegate to a Store
> >> instance.
> >>
> >> 3) Misc.
> >> There are a few I am investigating:
> >> 1) Spring/Guice under the hood.
> >> 2) JUnit 4.4 (and Hamcrest library)
> >> , but these are still in early stages.
> >>
> >> I am keen to get a feedback on what others think.
> >>
> >> Cheers,
> >>
> >> Rahul
> >>
> >>
> >> [1] -
> >> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/
> >>
> >> [2] - http://openjpa.apache.org/
> >>
> >> [3] -
> >>
> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/continuum-model-jpa/src/main/java/org/apache/maven/continuum/store/api/Store.java
> >>
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message