Hibernate (and JPA) offer of course a lot of great features, JPAQL is
are really powerfull object/relational query language, and have been
unable to find an ORM with better mapping capabilities than
Hibernate.
Validation, on the other hand is not an strong point for Hibernate.
(Yes Hibernate annotations are fine for simple validations, like not
null fields, or, maximum length or even matching regular expressions)
but you rapidly run in to problems if you need to do some serious
validation involving queries: It is "forbidden" by typical Hibernate
"good pratices" to call the entityManager from inside an Hibernate
@Entity. (In fact, there is no easy way to obtain the EntityManager
managing a particular Pojo).
So, while the @AssertTrue annotation should theoretically be able to
deal with any validation you imagine, in fact in can only validate
stuff involving fields in the same POJO instance (stuff like for
example, "your wedding date most be later than your birth date") but
if you need to complex conflict validation for example "validate
before saving" a "Meeting" POJO, and query the database to validate
that you do not have another meeting at the same time, and that all
the other persons invited to the meeting also do not have another
meeting at the same time. If you need to do that kind of validation,
you are on your own. (AFAIK you are not even supposed to use the
EntityManager inside your own validator classes, and even if you
could, there is no standard way to include contextual information in
you validation error message)
What Hibernate users typically do is that they validate this kind of
complex stuff outside of their POJOs, typically in the controller for
the page they were building when they realized they needed a
particular validation. The problem is that as the application evolves,
your POJOs end up being modified from several different pages, and
sooner or later you are going to forget to call a particular
validation... and before you realize you will have inconsistent
"Meetings" stored in you database.
AribaWeb by any chance can help alleviate this Hibernate limitation?
(Basically, you may have guessed it by now, I truly really deeply do
miss EOF validateForSave a lot)
Ariba's own (non-Hibernate, non-opensource) persistence framework does
have these hooks.
I don't see a problem with adding them to ObjectContext /
HibernateContext (in metaui.persistence and metaui-jpa) -- we can make
a pass through all to-be-committed objects and evaluate a class-level
metaui "valid" property on them before proceeding with the save. (We
can then automatically register metaui validation rules based on
specific annotations in your POJO classes, so it could end up looking
like validateForSave() in the degenerate case).
(I'm not sure we will get to this for 5.0GA, but we can probably
explore it shortly thereafter).
> Hibernate (and JPA) offer of course a lot of great features, JPAQL is
> are really powerfull object/relational query language, and have been
> unable to find an ORM with better mapping capabilities than
> Hibernate.
> Validation, on the other hand is not an strong point for Hibernate.
> (Yes Hibernate annotations are fine for simple validations, like not
> null fields, or, maximum length or even matching regular expressions)
> but you rapidly run in to problems if you need to do some serious
> validation involving queries: It is "forbidden" by typical Hibernate
> "good pratices" to call the entityManager from inside an Hibernate
> @Entity. (In fact, there is no easy way to obtain the EntityManager
> managing a particular Pojo).
> So, while the @AssertTrue annotation should theoretically be able to
> deal with any validation you imagine, in fact in can only validate
> stuff involving fields in the same POJO instance (stuff like for
> example, "your wedding date most be later than your birth date") but
> if you need to complex conflict validation for example "validate
> before saving" a "Meeting" POJO, and query the database to validate
> that you do not have another meeting at the same time, and that all
> the other persons invited to the meeting also do not have another
> meeting at the same time. If you need to do that kind of validation,
> you are on your own. (AFAIK you are not even supposed to use the
> EntityManager inside your own validator classes, and even if you
> could, there is no standard way to include contextual information in
> you validation error message)
> What Hibernate users typically do is that they validate this kind of
> complex stuff outside of their POJOs, typically in the controller for
> the page they were building when they realized they needed a
> particular validation. The problem is that as the application evolves,
> your POJOs end up being modified from several different pages, and
> sooner or later you are going to forget to call a particular
> validation... and before you realize you will have inconsistent
> "Meetings" stored in you database.
> AribaWeb by any chance can help alleviate this Hibernate limitation?
> (Basically, you may have guessed it by now, I truly really deeply do
> miss EOF validateForSave a lot)
On Feb 25, 11:33 pm, Craig Federighi <craig.federi...@gmail.com>
wrote:
> Ariba's own (non-Hibernate, non-opensource) persistence framework does
> have these hooks.
And I guess you are planning on waiting another 10 years before
releasing it as OpenSource, you are such sadistic person... ;-)
> I don't see a problem with adding them to ObjectContext /
> HibernateContext (in metaui.persistence and metaui-jpa) -- we can make
> a pass through all to-be-committed objects and evaluate a class-level
> metaui "valid" property on them before proceeding with the save. (We
> can then automatically register metaui validation rules based on
> specific annotations in your POJO classes, so it could end up looking
> like validateForSave() in the degenerate case).
So.... It is fine for me to use Ariba's ObjectContext /
HibernateContext inside my POJOs? The risk of crazy behavior due to
Hibernate lazy loading peculiarities is very low? or plain non
existent? (or do you have particular set of recommendations to share
that prevent those crazy interactions, I do not remember the exact
problems, but Gavin King is always recommending against doing queries
inside your POJOs, so feel uneasy about doing it)
> (I'm not sure we will get to this for 5.0GA, but we can probably
> explore it shortly thereafter).
Please, please do so! And if you need any help testing it, count me
on.
> So.... It is fine for me to use Ariba's ObjectContext /
> HibernateContext inside my POJOs? The risk of crazy behavior due to
> Hibernate lazy loading peculiarities is very low? or plain non
> existent?
I believe that the key is to not trigger any such access when
Hibernate could otherwise be in the middle of other persistence
operations. (I.e. the code is likely not safely re-enterent if the
getter or setter of a property (that would be accessed when processing
a fetch) could itself trigger a fetch).
We should be safe if we collect the objects to validate outside of any
Hibernate persistence processing (pre save) and then call validation
specifically designated validation methods (validateForSave(ctx)
equivalents) that are not otherwise called by Hibernate. In effect
this standardizes the pattern that you describe app pages/controller
doing explicitly into a general framework pattern.
> On Feb 25, 11:33 pm, Craig Federighi <craig.federi...@gmail.com>
> wrote:
>> Ariba's own (non-Hibernate, non-opensource) persistence framework
>> does
>> have these hooks.
> And I guess you are planning on waiting another 10 years before
> releasing it as OpenSource, you are such sadistic person... ;-)
>> I don't see a problem with adding them to ObjectContext /
>> HibernateContext (in metaui.persistence and metaui-jpa) -- we can
>> make
>> a pass through all to-be-committed objects and evaluate a class-level
>> metaui "valid" property on them before proceeding with the save. (We
>> can then automatically register metaui validation rules based on
>> specific annotations in your POJO classes, so it could end up looking
>> like validateForSave() in the degenerate case).
> So.... It is fine for me to use Ariba's ObjectContext /
> HibernateContext inside my POJOs? The risk of crazy behavior due to
> Hibernate lazy loading peculiarities is very low? or plain non
> existent? (or do you have particular set of recommendations to share
> that prevent those crazy interactions, I do not remember the exact
> problems, but Gavin King is always recommending against doing queries
> inside your POJOs, so feel uneasy about doing it)
>> (I'm not sure we will get to this for 5.0GA, but we can probably
>> explore it shortly thereafter).
> Please, please do so! And if you need any help testing it, count me
> on.
I read somewhere at the posts that any persistence framework capable
of extended persistence context can be used, or any stateful
application framework like Seam can be used since its capable of
utilizing extended persistence context.
Can I conclude that ObjectContext is using extended persistence
context and by doing so has no problem for (hibernate's) lazy
loading ?
how about the optimistic locking using @Version ? will it cause
problem if we use it ? coz no example is using it.. and is it
unnecessary because ObjectContext has its own way of managing it ?
tq,
-andre-
On Feb 27, 1:23 am, Craig Federighi <craig.federi...@gmail.com> wrote:
> > So.... It is fine for me to use Ariba's ObjectContext /
> > HibernateContext inside my POJOs? The risk of crazy behavior due to
> > Hibernate lazy loading peculiarities is very low? or plain non
> > existent?
> I believe that the key is to not trigger any such access when
> Hibernate could otherwise be in the middle of other persistence
> operations. (I.e. the code is likely not safely re-enterent if the
> getter or setter of a property (that would be accessed when processing
> a fetch) could itself trigger a fetch).
> We should be safe if we collect the objects to validate outside of any
> Hibernate persistence processing (pre save) and then call validation
> specifically designated validation methods (validateForSave(ctx)
> equivalents) that are not otherwise called by Hibernate. In effect
> this standardizes the pattern that you describe app pages/controller
> doing explicitly into a general framework pattern.
> - craig
> On Feb 25, 2009, at 9:53 PM, luxspes wrote:
> > Hi!
> > On Feb 25, 11:33 pm, Craig Federighi <craig.federi...@gmail.com>
> > wrote:
> >> Ariba's own (non-Hibernate, non-opensource) persistence framework
> >> does
> >> have these hooks.
> > And I guess you are planning on waiting another 10 years before
> > releasing it as OpenSource, you are such sadistic person... ;-)
> >> I don't see a problem with adding them to ObjectContext /
> >> HibernateContext (in metaui.persistence and metaui-jpa) -- we can
> >> make
> >> a pass through all to-be-committed objects and evaluate a class-level
> >> metaui "valid" property on them before proceeding with the save. (We
> >> can then automatically register metaui validation rules based on
> >> specific annotations in your POJO classes, so it could end up looking
> >> like validateForSave() in the degenerate case).
> > So.... It is fine for me to use Ariba's ObjectContext /
> > HibernateContext inside my POJOs? The risk of crazy behavior due to
> > Hibernate lazy loading peculiarities is very low? or plain non
> > existent? (or do you have particular set of recommendations to share
> > that prevent those crazy interactions, I do not remember the exact
> > problems, but Gavin King is always recommending against doing queries
> > inside your POJOs, so feel uneasy about doing it)
> >> (I'm not sure we will get to this for 5.0GA, but we can probably
> >> explore it shortly thereafter).
> > Please, please do so! And if you need any help testing it, count me
> > on.
> Can I conclude that ObjectContext is using extended persistence
> context and by doing so has no problem for (hibernate's) lazy
> loading ?
Right.
> how about the optimistic locking using @Version ? will it cause
> problem if we use it ? coz no example is using it.. and is it
> unnecessary because ObjectContext has its own way of managing it ?
You're right that the examples are a bit sloppy in that regard. Proper use of @Version is absolutely recommended.
(I was just relying on the home that Hibernate's JPA mapping would use
"optimistic-lock:all" by default if no @Version was specified).
Thanks,
- craig
On Mar 1, 2009, at 11:16 PM, andre.prasetya wrote:
> I read somewhere at the posts that any persistence framework capable
> of extended persistence context can be used, or any stateful
> application framework like Seam can be used since its capable of
> utilizing extended persistence context.
> Can I conclude that ObjectContext is using extended persistence
> context and by doing so has no problem for (hibernate's) lazy
> loading ?
> how about the optimistic locking using @Version ? will it cause
> problem if we use it ? coz no example is using it.. and is it
> unnecessary because ObjectContext has its own way of managing it ?
> tq,
> -andre-
> On Feb 27, 1:23 am, Craig Federighi <craig.federi...@gmail.com> wrote:
>>> So.... It is fine for me to use Ariba's ObjectContext /
>>> HibernateContext inside my POJOs? The risk of crazy behavior due to
>>> Hibernate lazy loading peculiarities is very low? or plain non
>>> existent?
>> I believe that the key is to not trigger any such access when
>> Hibernate could otherwise be in the middle of other persistence
>> operations. (I.e. the code is likely not safely re-enterent if the
>> getter or setter of a property (that would be accessed when
>> processing
>> a fetch) could itself trigger a fetch).
>> We should be safe if we collect the objects to validate outside of
>> any
>> Hibernate persistence processing (pre save) and then call validation
>> specifically designated validation methods (validateForSave(ctx)
>> equivalents) that are not otherwise called by Hibernate. In effect
>> this standardizes the pattern that you describe app pages/controller
>> doing explicitly into a general framework pattern.
>> - craig
>> On Feb 25, 2009, at 9:53 PM, luxspes wrote:
>>> Hi!
>>> On Feb 25, 11:33 pm, Craig Federighi <craig.federi...@gmail.com>
>>> wrote:
>>>> Ariba's own (non-Hibernate, non-opensource) persistence framework
>>>> does
>>>> have these hooks.
>>> And I guess you are planning on waiting another 10 years before
>>> releasing it as OpenSource, you are such sadistic person... ;-)
>>>> I don't see a problem with adding them to ObjectContext /
>>>> HibernateContext (in metaui.persistence and metaui-jpa) -- we can
>>>> make
>>>> a pass through all to-be-committed objects and evaluate a class- >>>> level
>>>> metaui "valid" property on them before proceeding with the save. >>>> (We
>>>> can then automatically register metaui validation rules based on
>>>> specific annotations in your POJO classes, so it could end up
>>>> looking
>>>> like validateForSave() in the degenerate case).
>>> So.... It is fine for me to use Ariba's ObjectContext /
>>> HibernateContext inside my POJOs? The risk of crazy behavior due to
>>> Hibernate lazy loading peculiarities is very low? or plain non
>>> existent? (or do you have particular set of recommendations to share
>>> that prevent those crazy interactions, I do not remember the exact
>>> problems, but Gavin King is always recommending against doing
>>> queries
>>> inside your POJOs, so feel uneasy about doing it)
>>>> (I'm not sure we will get to this for 5.0GA, but we can probably
>>>> explore it shortly thereafter).
>>> Please, please do so! And if you need any help testing it, count me
>>> on.
|
