<div>Hi,<br></div><div><br></div><div>Thanks for your reply.</div>
<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hmm, to me, this is not worth the complexity. If you want your domain<br>
to be in control of the transactions (as opposed to the user), I<br>
suggest signaling MagmaSessionRequests. See<br>
<a href="http://wiki.squeak.org/squeak/5605" target="_blank">http://wiki.squeak.org/squeak/5605</a> if you haven't already.<br></blockquote><div><br></div><div>I read that page, but did not fully comprehend it. I will look into it. <br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Wow, please do not do this approach, I agree it is way too complicated<br>
and definitely not the right way to use Magma.<br>
<br>
Please use MagmaSessionRequest (signalNoteOldKeysFor:, et al) and<br>
handle it in whatever app-level controller you're using. It is benign<br>
if it isn't handled, so transient applications will work<br>
transparently.<br>
</blockquote><div><br></div><div>I will give this a try. Did not know this existed.</div><div> <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Detecting key changes automatically was impossible without slowing<br>
down commits; the<br>
<br>
MagmaSessionRequest signalNoteOldKeysFor: myAttribute<br>
<br>
is so easy to just put into the appropriate setter, so it wasn't a<br>
good trade-off to compromise performance for this minor increase in<br>
transparency.<br></blockquote><div><br></div><div>On: <a href="http://wiki.squeak.org/squeak/5605" target="_blank">http://wiki.squeak.org/squeak/5605</a> 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. <br>
</div><div><br></div><div>I will try out option 2) because the other I suggested is just too complex. </div><div>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. </div>
<div><br></div><div>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 ...).</div>
<div><br></div><div>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 ...</div><div><br></div><div>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.</div>
<div><br></div><div>Kind Regards,</div><div><br></div><div>Bart</div><div><br></div></div>