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.
