You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by 101questionjsf <in...@yahoo.com> on 2006/04/05 11:44:33 UTC
JDBC and Hibernate
hi all,
Currently, i'm using JDBC statements, and using Oracle db. But got a feeling
these JDBC statements are going to be Oracle specific... Please help me
confirm this is true?
If using Hibernate, will it tie to Oracle db or it will be regardless of the
backend db, it can just run in any db without any modification
--
View this message in context: http://www.nabble.com/JDBC-and-Hibernate-t1398402.html#a3761141
Sent from the MyFaces - Users forum at Nabble.com.
Re: JDBC and Hibernate
Posted by Larry Meadors <lm...@apache.org>.
If you have existing SQL and are comfortable with it, you may want to
look at using iBATIS for your database access, too:
http://ibatis.apache.org
It is a data mapper, meaning that it maps your sql to java objects
instead of an ORM that maps database objects to java objects.
Larry
On 4/5/06, 101questionjsf <in...@yahoo.com> wrote:
>
> hi all,
>
> Currently, i'm using JDBC statements, and using Oracle db. But got a feeling
> these JDBC statements are going to be Oracle specific... Please help me
> confirm this is true?
>
> If using Hibernate, will it tie to Oracle db or it will be regardless of the
> backend db, it can just run in any db without any modification
> --
> View this message in context: http://www.nabble.com/JDBC-and-Hibernate-t1398402.html#a3761141
> Sent from the MyFaces - Users forum at Nabble.com.
>
>
Re: JDBC and Hibernate
Posted by Matthias Wessendorf <mw...@gmail.com>.
Since there are lot's of mentioned frameworks ...
Spring DAO is also nice to use. I like Spring's JDBCTemplate. Easy to
use with SQL and no aditional object-based layer, like Hibernate, is
needed.
-Matthias
On 4/5/06, Alexandre Poitras <al...@gmail.com> wrote:
> And EJB3 is heavily inspired of Hibernate. Really I wouldn't go the
> JDO way. By the way, JPA is going to be the official persistence
> specification.
>
> On 4/5/06, Jonathan Harley <jo...@parkplatz.net> wrote:
> > 101questionjsf wrote:
> > > Currently, i'm using JDBC statements, and using Oracle db. But got a feeling
> > > these JDBC statements are going to be Oracle specific... Please help me
> > > confirm this is true?
> >
> > Very likely. Oracle's dialect of SQL is proprietary.
> >
> > > If using Hibernate, will it tie to Oracle db or it will be regardless of the
> > > backend db, it can just run in any db without any modification
> >
> > No, it won't tie you to Oracle if you use HQL as your query language, as it
> > is database-neutral. However, it will tie you to Hibernate!
> >
> > You might want to look at JDO, which is the current standard for using
> > databases (and other kinds of datastore) from Java. There are over a dozen
> > implementations of the JDO standard, some commercial and some free like
> > JPOX. As it's a standard, it's trivial to switch between products as long
> > as you don't use vendor extensions (and as JDO is a mature standard, you
> > probably won't need to). If you want to avoid being tied to one
> > vendor, standards are always the way to go.
> >
> >
> > Jon
> > --
> > .....................................................................
> > Dr Jonathan Harley .
> > . Email: jon@parkplatz.net
> > Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
> > www.parkplatz.net . Mobile: 079 4116 0423
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: JDBC and Hibernate
Posted by Alexandre Poitras <al...@gmail.com>.
And EJB3 is heavily inspired of Hibernate. Really I wouldn't go the
JDO way. By the way, JPA is going to be the official persistence
specification.
On 4/5/06, Jonathan Harley <jo...@parkplatz.net> wrote:
> 101questionjsf wrote:
> > Currently, i'm using JDBC statements, and using Oracle db. But got a feeling
> > these JDBC statements are going to be Oracle specific... Please help me
> > confirm this is true?
>
> Very likely. Oracle's dialect of SQL is proprietary.
>
> > If using Hibernate, will it tie to Oracle db or it will be regardless of the
> > backend db, it can just run in any db without any modification
>
> No, it won't tie you to Oracle if you use HQL as your query language, as it
> is database-neutral. However, it will tie you to Hibernate!
>
> You might want to look at JDO, which is the current standard for using
> databases (and other kinds of datastore) from Java. There are over a dozen
> implementations of the JDO standard, some commercial and some free like
> JPOX. As it's a standard, it's trivial to switch between products as long
> as you don't use vendor extensions (and as JDO is a mature standard, you
> probably won't need to). If you want to avoid being tied to one
> vendor, standards are always the way to go.
>
>
> Jon
> --
> .....................................................................
> Dr Jonathan Harley .
> . Email: jon@parkplatz.net
> Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
> www.parkplatz.net . Mobile: 079 4116 0423
>
--
Alexandre Poitras
Québec, Canada
Re: JDBC and Hibernate
Posted by Alexandre Poitras <al...@gmail.com>.
I think JPA remains unfinished for the moment mainly for political
reasons. The final draft has been accepted if I remember correctly.
Anyway you can choose what you prefer but I think you went a little
bit too hard on Hibernate. I know the JDO community don't like Gavin
King and have their own vision but Hibernate is a true masterpiece. It
is very lightweight so you don't have a lot of depencencies on the
framework itself. You would just have a lot of configuration
information to migrate but right now Hibernate is the "de facto"
standard in the persistance area for most people so I guess you won't
have to migrate in the near future.
On a side note, what I like about JPA is that finally there is a first
official Java aspect. Just hope to see more in the future
(transaction, security, pooling, remote access, ...) so everything can
run in a standard VM and you don't have to deal with the complexity of
what you don't want. Well I am wandering far away from JSF right now
but well I really like AOP :) I agree with the JBoss guys, this is the
future of middleware services.
On 4/5/06, Jonathan Harley <jo...@parkplatz.net> wrote:
> 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.
>
> >>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.
>
> 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.
>
>
> Jon
> --
> .....................................................................
> Dr Jonathan Harley .
> . Email: jon@parkplatz.net
> Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
> www.parkplatz.net . Mobile: 079 4116 0423
>
--
Alexandre Poitras
Québec, Canada
Re: JDBC and Hibernate
Posted by Jonathan Harley <jo...@parkplatz.net>.
Werner Punz wrote:
> Jonathan Harley schrieb:
>>Werner Punz wrote:
>>>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,
Sure it does! Having problems is exactly what makes a bad API. Being
less powerful than previous APIs and current implementations also
makes a bad API. JPA is a "lowest common denominator" standard.
> of all attempts to unify the ORM OODB layers
> under a common standard this is one of the best so far.
Well, I disagree, I've given one concrete example and
there are plenty more. Just saying "it's really good" won't do.
It's a subset of JDO and a subset of Hibernate. I for one am
disappointed about that. It's true that there will be excellent
products based on it, some open source - but most of the best
things about those will be the parts that extend the standard.
One could argue that the same is true of JSF - a lot of the things
in tomahawk are there to cover deficiencies in the JSF standard. I
think that reveals a problem with the standard - it should never
have mandated the HTML tag library, with its table-based rendering,
reliance on JavaScript, XML-breaking id tags and so on. To me,
the brilliant things about JSF are the extensible architecture and
use of POJOs/dependency injection. Maybe the standard should have
focussed just on these.
>>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.
I agree, JSF 1.0 had problems and 1.2 is looking better, and I look
forward to future versions getting better still with techniques from
facelets and AJAX being incorporated. 1.0 standards always have their
problems. I just think it's a shame that the EJB people took a "not
invented here" attitude to some of the good things in JDO and made some
mistakes that could easily have been avoided. So far, I'm hopeful that
that isn't happening in the JSF world, as the JSP/JSF specs seem to
be much more open to using the best ideas around.
Jon
--
.....................................................................
Dr Jonathan Harley .
. Email: jon@parkplatz.net
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
Re: JDBC and Hibernate
Posted by Mike Kienenberger <mk...@gmail.com>.
On 4/6/06, Alexandre Poitras <al...@gmail.com> wrote:
> Nice strategy :) Spring give you this out-of-the-box with its template
> concept and general DAO exceptions.
Exactly. I'm not much of a spring user, but now that you pointed it
out, I'm reading up on Spring's template approach and my approach was
definitely inspired by the Spring templates concept. I started with
the Cayenne-spring template library and dumped the spring part (it
wasn't adding anything for me and it didn't work well with JSF).
For anyone else who is interested, take a look at the following url,
but keep in mind that there's really nothing here that requires Spring
if you don't want to add a Spring dependency.
http://www.springframework.org/docs/reference/orm.html
Alexandre, thanks for pointing this out.
Re: JDBC and Hibernate
Posted by Matthias Wessendorf <mw...@gmail.com>.
On 4/6/06, Alexandre Poitras <al...@gmail.com> wrote:
> Nice strategy :) Spring give you this out-of-the-box with its template
> concept and general DAO exceptions.
Yeah! I like it to makes it pretty easy! And it's fast!
Re: JDBC and Hibernate
Posted by Alexandre Poitras <al...@gmail.com>.
Nice strategy :) Spring give you this out-of-the-box with its template
concept and general DAO exceptions.
On 4/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> 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 <we...@gmx.at> 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.
> >
> >
> >
> >
> >
>
--
Alexandre Poitras
Québec, Canada
Re: JDBC and Hibernate
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <we...@gmx.at> 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.
>
>
>
>
>
Re: JDBC and Hibernate
Posted by Werner Punz <we...@gmx.at>.
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.
Re: JDBC and Hibernate
Posted by Jonathan Harley <jo...@parkplatz.net>.
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.
>>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.
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.
Jon
--
.....................................................................
Dr Jonathan Harley .
. Email: jon@parkplatz.net
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
Re: JDBC and Hibernate
Posted by Werner Punz <we...@gmx.at>.
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, lets say it that way from its
amount it covers pretty much everything Hibernate 3.0 has to offer, it
just starts now that Hibernate for instance offers more than standard
JPA and those areas do not have to be used.
I was really surprised that JPA is as extensive as it is given my
experiences on those isses in the past. I once was burned with the OMG
1.0 standard and other so called standards which merely were non working
marketing papers.
And there is no real reason why JPA cannot work on an object storage as
well. In fact Versant is working on a JPA version for their own stuff or
already has it in place.
> 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)
One thing for instance where it can make sense to lock yourself into a
vendor API is if you want to use a delete abandoned entities feature.
But most db apps I worked with never had the intention to use such a
garbage colleciton mechanism on an active database.
Re: JDBC and Hibernate
Posted by Jonathan Harley <jo...@parkplatz.net>.
Werner Punz wrote:
> Jonathan Harley schrieb:
>>You might want to look at JDO, which is the current standard for using
>>databases (and other kinds of datastore) from Java.
>
> Actually no all things currently settle around javax.persistence (jpa)
Not currently, no. JPA is a proposed standard, whereas JDO is the
current standard - it has been around for several years. And when JPA
is finalised, JDO 2.0 (which passed its final ballot just last month)
will exist alongside it.
> jdo and others (Hibernate) will be available as extensions and base
> frameworks around that one.
Indeed. Because JPA is such a limited standard (only covers
relational datastores, for one thing), 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.
Jon
--
.....................................................................
Dr Jonathan Harley .
. Email: jon@parkplatz.net
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
Re: JDBC and Hibernate
Posted by Werner Punz <we...@gmx.at>.
Jonathan Harley schrieb:
> You might want to look at JDO, which is the current standard for using
> databases (and other kinds of datastore) from Java.
Actually no all things currently settle around javax.persistence (jpa)
jdo and others (Hibernate) will be available as extensions and base
frameworks around that one.
Re: JDBC and Hibernate
Posted by Jonathan Harley <jo...@parkplatz.net>.
101questionjsf wrote:
> Currently, i'm using JDBC statements, and using Oracle db. But got a feeling
> these JDBC statements are going to be Oracle specific... Please help me
> confirm this is true?
Very likely. Oracle's dialect of SQL is proprietary.
> If using Hibernate, will it tie to Oracle db or it will be regardless of the
> backend db, it can just run in any db without any modification
No, it won't tie you to Oracle if you use HQL as your query language, as it
is database-neutral. However, it will tie you to Hibernate!
You might want to look at JDO, which is the current standard for using
databases (and other kinds of datastore) from Java. There are over a dozen
implementations of the JDO standard, some commercial and some free like
JPOX. As it's a standard, it's trivial to switch between products as long
as you don't use vendor extensions (and as JDO is a mature standard, you
probably won't need to). If you want to avoid being tied to one
vendor, standards are always the way to go.
Jon
--
.....................................................................
Dr Jonathan Harley .
. Email: jon@parkplatz.net
Zac Parkplatz Ltd . Office Telephone: 024 7633 1375
www.parkplatz.net . Mobile: 079 4116 0423
AW: JDBC and Hibernate
Posted by Matthias Kahlau <mk...@web.de>.
It depends on which Hibernate functions and SQL features you'll use.
When you use SQL subselects, for instance, I think this won't be supported
by all dbs ...
-Matthias
> -----Ursprungliche Nachricht-----
> Von: users-return-19811-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-19811-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von 101questionjsf
> Gesendet: Mittwoch, 5. April 2006 11:45
> An: users@myfaces.apache.org
> Betreff: JDBC and Hibernate
>
>
>
> hi all,
>
> Currently, i'm using JDBC statements, and using Oracle db. But
> got a feeling
> these JDBC statements are going to be Oracle specific... Please help me
> confirm this is true?
>
> If using Hibernate, will it tie to Oracle db or it will be
> regardless of the
> backend db, it can just run in any db without any modification
> --
> View this message in context:
> http://www.nabble.com/JDBC-and-Hibernate-t1398402.html#a3761141
> Sent from the MyFaces - Users forum at Nabble.com.
>