A few word about Magma+Seaside experience

[Chris Muller]

Hi,

On 4/7/07, Hilaire Fernandes <hilaire2006 at laposte.net> wrote:
> Ok, I think I have sorted out my index and persistence problem.
>
> 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..

> Instead I have been experiencing design problem when using
> the combination of Magma+Seaside, and in particular the
> continuation/back-button or whatever it is named.

Ah, the back button, what a shock..

> I found it was pretty neat to used seaside+magma that way:
>
> IFIDbSession
>     commit: [IFIDbSession noteOldKeyFor: learner.
>        self call: ((IFILearnerView new)
>           school: school;
>           learner: learner)]
>
> I found it will optimize the transaction as all the changed attributes
> of the learner object through the view component will be updated in the
> DB in one shot.
> This work pretty well but when the user decides to press the back
> button, so in this case the commit never has a chance to terminated (I
> guess so). So latter tentative to commit will never happen. This is at
> least what I saw.

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.

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..

> 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..

> Will the MagmaSessionRequest be an option to group in batch the commit?
> How is it handled when several MagmaSession instances co-exist in the
> same image?

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.

> So when using Seaside/Magma beware to not mix commit: and call:

Hilaire, I thought your application was a pure image application, not
a web application..  I thought this because you were using multiple
sessions talking directly ot the Magma server over the Internet,
weren't you?.  So it is a web application afterall?  I really enjoyed
the screenshots you posted the other week, but can you share some more
information your project?

Thanks,
  Chris