Problem updating loaded children with cascaded save

[horizon]

What would you think of the behavior I have documented here:

http://www.pareis.com/2011/04/26/beware-of-this-play-frameworks-cascaded-save-only-works-on-loaded-collections/

[horizon]

Sorry my initial message was a bit short. Let me give you a brief
introduction again:

There is obviously a problem associated with play's JPA extension/
modification. If I load objects using some query which should normally
be reachable by cascade from a save()d parent object, then this
cascade only takes place if I manually force population of the
association from the DB. Details and sample code to be found here:
http://www.pareis.com/2011/04/26/beware-of-this-play-frameworks-cascaded-save-only-works-on-loaded-collections/

I would be interested in other opinions about this as I am unsure
wether to continue development with that issue always in mind or to
switch back to plain JPA.

[Guillaume Bort]

That's true that the hack to the standard JPA lifecycle has
implications. So just be aware of them and make sure that tricky cases
are correctly tested to avoid any future regression, or switch to
standard JPA.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

[horizon]

Thanks Guillaume, I find it funny that you call your own extensions a
"hack" ;)

Do you think that this observation would be worth being mentioned
somewhere in your JPA related docs? I mean, in standard JPA it's the
object graph (all loaded objects) that matters, in your "hack" it is
the loaded objects reachable from the starting point only. You should
really document that.

[Guillaume Bort]

On Wed, Apr 27, 2011 at 6:19 PM, horizon <andre....@gmail.com> wrote:
> Thanks Guillaume, I find it funny that you call your own extensions a
> "hack" ;)

It's clearly a hack. I've chosen to go with Hibernate at first because
it is probably the best you can get with Java. But its stateful
orientation doesn't match perfectly with Play.

>
> Do you think that this observation would be worth being mentioned
> somewhere in your JPA related docs? I mean, in standard JPA it's the
> object graph (all loaded objects) that matters, in your "hack" it is
> the loaded objects reachable from the starting point only. You should
> really document that.

Yes, if you can, please provide a push request with the documentation update.

>
>
> On Apr 27, 6:04 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
>> That's true that the hack to the standard JPA lifecycle has
>> implications. So just be aware of them and make sure that tricky cases
>> are correctly tested to avoid any future regression, or switch to
>> standard JPA.
>

[Pascal Voitot Dev]

On Wed, Apr 27, 2011 at 6:25 PM, Guillaume Bort <guillau...@gmail.com> wrote:

On Wed, Apr 27, 2011 at 6:19 PM, horizon <andre....@gmail.com> wrote:
> Thanks Guillaume, I find it funny that you call your own extensions a
> "hack" ;)

It's clearly a hack. I've chosen to go with Hibernate at first because
it is probably the best you can get with Java. But its stateful
orientation doesn't match perfectly with Play.

For information (and not only saying this for preaching my own chapel), 2 days ago, I've made work Siena+Play+(H2/Mysql/Postgres+DDL or GAE) and it makes me happy as it works like a charm and I now have a simple alternative to JPA which is fully stateless by default and more compliant to what I intend from a DB API in a web app!
 

[horizon]

On Apr 27, 6:25 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> It's clearly a hack. I've chosen to go with Hibernate at first because
> it is probably the best you can get with Java. But its stateful
> orientation doesn't match perfectly with Play.

I see the point. There are many parts that I like in your hack and
some that I might not. For instance, I would clearly not want to lose
all the neat find methods, and generated getter/setter code. If I
chose to derive my model objects not from JPABase I would lose all
those welcome features I guess. But I would really like to keep those,
derive further from Model but have the stateful JPA behavior back. Do
you see a chance that you might come up with some config to control
wether the commit extension is used or not? I mean, I have seen in the
JPAPlugin that you have just added that Interceptor to tell hibernate
that there are no changed objects... would it be possible to just
remove that interceptor? Or better, have some config option to control
wether you use that interceptor or not?

Thanks!

[Andre Pareis]

Hi Guillaume,

do you think it would be possible to configure standard JPA vs. play
mode in the application.conf without losing the features of having
play.db.Model as the base class? I see in the code that it is
basically only that interceptor.

Thanks for any response,
Andre