Why is MagmaSession>>#noteOldKeysFor: necessary?

Bart Gauquie bart.gauquie at gmail.com
Mon Jan 4 21:33:37 UTC 2010


Hi,

Thanks for your reply.

Hmm, to me, this is not worth the complexity.  If you want your domain
> to be in control of the transactions (as opposed to the user), I
> suggest signaling MagmaSessionRequests.  See
> http://wiki.squeak.org/squeak/5605 if you haven't already.
>

I read that page, but did not fully comprehend it. I will look into it.

Wow, please do not do this approach, I agree it is way too complicated
> and definitely not the right way to use Magma.
>
> Please use MagmaSessionRequest (signalNoteOldKeysFor:, et al) and
> handle it in whatever app-level controller you're using.  It is benign
> if it isn't handled, so transient applications will work
> transparently.
>

I will give this a try. Did not know this existed.


> Detecting key changes automatically was impossible without slowing
> down commits; the
>
>  MagmaSessionRequest signalNoteOldKeysFor: myAttribute
>
> is so easy to just put into the appropriate setter, so it wasn't a
> good trade-off to compromise performance for this minor increase in
> transparency.
>

On: http://wiki.squeak.org/squeak/5605 you mention that option 3) autocommit
is completely transparent. I disagree, since the signalNoteOldKeys message
on a session is absolutely necessary to make it work correctly. I can
understand your reasoning about the performance hit if you have to check
everything.

I will try out option 2) because the other I suggested is just too complex.
I still have my doubts about the transparency of this option. Out of
experience I know that most code is modified after being written. What the
developer now has to remember is that if an index is added to some magma
collection is to add the signalNoteOldKeys: in the mutator of it. Thats
error prone. That is the reason I tried to do that completely automatically.
You set up it correct one time and move on, just don't have to think about
it again.

The index I'm trying to create makes this more error prone: I have a root
object which is in a MagmaCollection. It has a keywords index. The keywords
are made up of a list which contains multiple fields of the root object but
also of a list of fields of the sub objects of this root. Using this, I can
implement a kind of google search box in which you can find keywords
dispersed over my entire domain and let Magma retrieve the correct aggegrate
root, and I would not have to integrate any kind of full text search
technology to do this. The reason I wanted it to be transparent is that if I
for instance add a new field on this keywords list, I now have to remember
the signalNoteKeys on this setter, (which is error prone ...).

You say that it is slow. Did Magma once provide this auto notify keys
functionality? I think I could maybe live with the bit slower performance
...

Please don't get me wrong. I think Magma is great. Just got to know it
better. And if it turns out that it is not completely transparent, I shall
happily adapt the somewhat less transparent solution.

Kind Regards,

Bart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20100104/d9854072/attachment.htm


More information about the Magma mailing list