A few word about Magma+Seaside experience

[Hilaire Fernandes]

Chris Muller a écrit :

>> In fact the problem does not come from the indexes, thoses ones work
>> pretty well.
> 
> I was not expecting to find real bugs with the indexes because they
> have undergone such extensive testing.  Glad to hear that..

I understand you fell glad about that :)


> This explains why things appeared "not to be persisted" because you
> had Magma in a nested transaction; and only after committing the
> outer-most transaction do things become persisted.

Not to say the image were growing as hell.

> Recall the implementation of commit:
> 
> commit: aBlock
>     | result |
>     self begin.
>     result _ aBlock value.
>     self commit.
>     ^result
> 
> So when the back-button is pressed, it's the same effect as returning
> from a commit block, which leaves the session one level deeper in
> uncommitted transactions.
> 
> Have you tried this?
> 
>  IFIDbSession
>      commit: [IFIDbSession noteOldKeyFor: learner.
>         self call: ((IFILearnerView new)
>            school: school;
>            learner: learner)].
>  IFIDbSession abort
> 
> This way, if they use the back button in the middle of the call to
> IFILearnerView, will Seaside resume with the IFIDbSession abort?  At
> least that would remove, from Magma session, all levels of
> transactions..

I thought about that, however the server never knows when the user 
presses the back button, so the abort is not executed when the back 
button is pressed.
Eventually an abort just before the commit: will do it..
What do you think? I am really not sure an abort before a commit and 
with a pending commit will do the trick, at least I do not know how to 
measure the scope of such a situation.

> 
>> To fix that I have moved the commit down in accessors of the learner
>> class, for example:
>>
>> IFILearner>>firstName: string1
>>         IFIDbSession commit:
>>                 [IFIDbSession noteOldKeyFor: self.
>>                 firstName := string1]
>>
>> Now I found the process of updating/adding such instances/attributes
>> seems to be slower, as several attributes are updated that way. I will
>> need to measure exactly...
> 
> Yeah, updating one attribute at a time will require many more trips to
> the server.  Besides that, it may not have the proper atomicity you
> desire.  You shouldn't have to compromise like that..

Yes the atomicity is not great as I may also want to check for the validity.


> MagmaSessionRequest is nothing more than a resumable Notification.  At
> some place, higher in your call stack, you wrap it in a on:do: and
> catch the MagmaSessionRequest, being sure to resume it.  But I have no
> idea whether it would work inside a Seaside called component that is
> handled in the calling component..  Sorry.

Nevertheless, the cost will be the same if I understand correctly.

Thanks

Hilaire