Magma and Magma on Pharo questions

[Keith Hodges]

Chris Muller wrote:
> Hi all,
>
>   
>> It also contains a mechainism for multiple applications to merge onto a
>> single db. So for example a user logins component, can be running
>> alongside a store-products component.
>>     
>
> Very interesting.  My preference (and recommendation) is to partition
> domains into multiple _separate_ physical repositories.  References to
> specific objects in other physical repositories are handled by way of
> the MagmaForwardingProxy, resulting in a view of a huge logical
> repository from a single MagmaSession instance.
>
> Multiple physical repositories scale much better than a single
> repository, due to running on multiple cores, multiple network paths,
> etc.  It's also easier for DB management as the domain grows with new
> dependent domains..
>
> Application client-sessions don't need to keep track of all of the
> separate locations of each physical repository, the locations are
> persisted in the MagmaForwardingProxy instances themselves.  Just
> connect to the "root" repository.  When that session encounters a
> persistent MagmaForwardingProxy, a session is created automatically,
> if necessary.  (MFP instances are created by sending,
> #asMagmaFowardingProxy to any object).
>
>  - Chris
>   
This seems a little too much for what is basically individual tables
within a database for an individual application.

All that the seasideHelper mechanism does is allow the "root" for the
user login table to know its position in the database relative to the
actual root. Thus you could break out a table into a separate repository
at a later stage if you wanted to.

Keith