Both OpenEJB and Cayenne are currently in incubation and will support
OpenJPA. Cayenne is an alternative to Hibernate (ORM).
For what it's worth, my approach has been to create "DataStore"
interfaces, each of which has database-layer independent methods for
creating, deleting, updating, and searching for database entities. I
believe this is a variation on the DAO approach.
I then have a CayenneDataStore implementation that handles the
database layer. It could easily be replaced by a HibernateDataStore
or some other database layer.
This keeps all of the database layer-specific code out of my app code
and in the datastore class. Best of all, I can use code generation
based on my Cayenne database model to build 80% of all the code in
DataStore (using the gap generation pattern). Thus, all I need to
implement myself are additional custom-purpose searching methods
(findUserByLoginId, etc) and add them to my interface. These tend to
be trivial to implement under Cayenne:
public Individual findIndividualByFirstInitialAndLastName(
String firstNameInitial, String lastName)
{
List andedExpressionList = new ArrayList();
andedExpressionList.add(ExpressionFactory.matchExp(Individual.LAST_NAME_PROPERTY,
lastName));
andedExpressionList.add(ExpressionFactory.likeIgnoreCaseExp(Individual.FIRST_NAME_PROPERTY,
firstNameInitial + "%"));
return
(Individual)findDataObjectByAndedExpressionList(andedExpressionList,
com.gvea.admindb.entity.cayenne.Individual.class);
}
If for some reason I need to switch from Cayenne to Hibernate or to
some in-house database layer, or to OpenJPA, then all I need to do is
create a new DataStore implementation.
On 4/6/06, Werner Punz <[EMAIL PROTECTED]> wrote:
> Jonathan Harley schrieb:
> > Werner Punz wrote:
> >> Jonathan Harley schrieb:
> >>> Indeed. Because JPA is such a limited standard (only covers
> >>> relational datastores, for one thing),
> >>
> >> Actually that is not quite true, JPA is not really limited
> >> to relational datastores
> >
> > Well, I suppose not but its query language is (yet another) dialect
> > of SQL and it uses SQL and relational terminology throughout its
> > annotations. It's clear what its designers had in mind.
> >
> Well object query sql derivates have been in existence for years now.
> I even can remember that the ODMG 1.0 standard had such a thing.
> This is no clear indication of trying to push the mapper towards
> relational dbs only.
>
> The problem with all those is and in my opinion generally with OO
> querying, there is up until now no clean we can cover all way to do the
> queries. OQL and derivates only go a certain way, then you have to
> follow different approaches. I never liked the we build our own query
> tree approach some orm mappers follow. In the end I think 95-99%% OQL or
> similar stuff, 5-1% different querying methods usually work best.
>
> The main difference the current approaches compared to Object Querying
> languages only approaches of the past are that nowadays fallbacks are
> allowed and expected.
>
> >>> JDO products as well as
> >>> Hibernate and Toplink will offer many extensions to the JPA standard.
> >>> Users will have a choice of using proprietary extensions (in the
> >>> case of Hibernate and Toplink) that lock them in to one vendor, or
> >>> standardised extensions (JDO) that give them a wide choice of vendor.
> >>
> >> Exactly, but the point is, there are no key issues why you have to lock
> >> yourself into it.
> >> In the future it probably will be, that it is best to code against jpa
> >> and use the extensions wisely, if needed (and in most cases it wont be
> >> needed)
> >
> > I disagree; I think it will be almost impossible not to use vendor
> > extensions. Take lazy loading, for example. JDO 2.0 defines exactly
> > which fields are available when an object is used while "detached"
> > from the store, and defines the exception which is thrown if client
> > code tries to access a different field. In Hibernate, whether access
> > succeeds depends on whether the field was already loaded, but a lazy
> > loading exception is thrown if not. In JPA, no particular behaviour
> > is defined, the spec merely observes that it might be "unsafe". If
> > you're using Hibernate JPA, no doubt you'll get the PROPRIETARY
> > Hibernate lazy loading exception, but using another vendor you
> > might just get null.
> >
> It is not perfect, but since most people proably will settle around
> OpenJPA, Hibernate and the RI, I do not see this case exactly as a big
> problem, because all three are opensource.
> Anyway there are areas where a fix is needed, but that does not mean
> that the JPA is a bad API, of all attempts to unify the ORM OODB layers
> under a common standard this is one of the best so far.
>
> > Maybe this discussion is wandering a bit far away from JSF. The
> > point I wanted to make is that if you like JSF because it's a
> > standard which gives you the choice to change vendor (and that's
> > certainly one of the things I use to persuade our clients that JSF
> > is good) then you should also look at standards for other areas
> > such as persistence. JPA is obviously worth a look, but right now
> > it's unfinished and seems to me quite poorly thought out.
> >
> No standard is ever finished, JSF 1.0 was a huge construction site,
> but with its third
> incarnation (1.2) it is getting where it covers most grounds currently
> needed.
> And from what I have looked at, JPA is clearly a winner, all it needs is
> some more flesh in some areas, but there always is the option for a JDO
> and Hibernate fallback in 5% of the areas where needed and with OpenJPA
> we soon will have an excellent JPA solution under the Apache umbrella
> with one of the best ORM codebases in existence.
>
> (Basically from what I could gather, the BEA KODO JPA donation will
> become Apache OpenJPA)
>
> As it seems all vendors rally behind JPA currently so the signs are
> pretty clear, most people like it due to it being close to Hibernate,
> and the vendors support it and there is a good set of already proven
> codebases implementing it out there in the wild as OSS.
>
>
>
>
>
