Smalltalk › Frameworks & Tools › GLORP

Ensuring initialization/computation before commiting

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Esteban A. Maringolo

Ensuring initialization/computation before commiting

Yesterday I faced an issue with the initialization of a lazily initialized object, which attempted to materialize a proxy during the commit phase.

short version:

Is there a method on which I can hook (redefine) to initialize any pending Proxies or precompute some values prior to the RowMap generation during a commit phase?

Long version:

I have anOrder that has a collection (1:n) of StatusChange.

But because of performance issues, anOrder also have an #status instVar referencing the last Status.

This way I can filter and query instances of Order without having to read the whole collection of status changes for each of the orders.

The same goes for #approvalDate, which will be lazy initialized if it's nil, looking for the last approved status in the collection of status changes (#statusHistory instVar).

The problem arises when I do something like:

session inUnitOfWorkDo: [ :session |

order := self app read: TsOrderNotice withId: id.

Because the order didn't initialize its #statusHistory collection, when it is generating its rowmap it fails to do so, because the calculation of #approvalDate needs to materialize the collection (and many of the objects referenced).

If I do this:

session inUnitOfWorkDo: [ :session |

order := self app read: TsOrderNotice withId: id.

order approvalDate "line added"

It works okay.

I can add an #ensure... method to my domain objects, doing what's needed on each of them. But maybe the framework already sends a message to the object prior to its persistence.

Any comments?

Regards!

Esteban.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Alan Knight-2

Re: Ensuring initialization/computation before commiting

Generally, the answer is that it shouldn't do that, and it shouldn't have to. When you're generating the rowmap, if the mapping sees it has an uninstantiated proxy it should just stop. If it doesn't put a value in the rowmap, that's fine, it's treated as not having changed. You don't have to read an object completely in order to be able to write it. I'm guessing that what happens here is that something indirectly causes that, either a computed value that in turns fires a proxy or, um, I'm not sure what. So if you're calculating the approval date yourself and something maps it, that's probably what's triggering it. But you shouldn't have to write the approval date if it's derived from other information that's already known.

On Wed Dec 10 2014 at 11:49:41 AM Esteban A. Maringolo <[hidden email]> wrote:

Yesterday I faced an issue with the initialization of a lazily initialized object, which attempted to materialize a proxy during the commit phase.

short version:
Is there a method on which I can hook (redefine) to initialize any pending Proxies or precompute some values prior to the RowMap generation during a commit phase?

Long version:
I have anOrder that has a collection (1:n) of StatusChange.
But because of performance issues, anOrder also have an #status instVar referencing the last Status.

This way I can filter and query instances of Order without having to read the whole collection of status changes for each of the orders.

The same goes for #approvalDate, which will be lazy initialized if it's nil, looking for the last approved status in the collection of status changes (#statusHistory instVar).

The problem arises when I do something like:
session inUnitOfWorkDo: [ :session |
order := self app read: TsOrderNotice withId: id.
].

Because the order didn't initialize its #statusHistory collection, when it is generating its rowmap it fails to do so, because the calculation of #approvalDate needs to materialize the collection (and many of the objects referenced).

If I do this:
session inUnitOfWorkDo: [ :session |
order := self app read: TsOrderNotice withId: id.
order approvalDate "line added"
].
It works okay.

I can add an #ensure... method to my domain objects, doing what's needed on each of them. But maybe the framework already sends a message to the object prior to its persistence.

Any comments?

Regards!

--
Esteban.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.