Object identity

Florian Minjat florian.minjat at emn.fr
Fri Jun 15 14:32:56 UTC 2007 

Thanks a lot for this great tutorial Chris !
It will help me a lot to optimise my application.
I will inform you if I have some difficulties or questions.
Thanks again for Magma :)

Florian

Chris Muller wrote:
>> First of all, how long will the read strategy last for a given session
>> by doing mySession 'session readStrategy: myReadStrategy.' ?
> 
> It will last until you replace it with another ReadStrategy.
> 
>> Do I have
>> to revert it back to a default strategy after my specific queries ?
> 
> Yes.  If you have a specific query you need to optimise by changing
> the depths of certain variables of certain classes, you will probably
> want to revert to your "default" strategy afterward, otherwise the
> specific-query strategy will continue to be used.
> 
>> For example : my Players have
>> a reference to a Dungeon which references a Desk which has two
>> OrderedCollection referencing Letters. If I want to send a Letter to
>> 10 Players, I need to had a Letter in each of their Desk, resulting of
>> a huge query I think. Is there a way to be so much specific with a
>> ReadStrategy ?
> 
> Let's see here.
> 
>    Player --->(1) Dungeon --->(1) Desk --->(*) Letter
> 
> So, for this operation (sending a single Letter to 10 Players), use a
> ReadStrategy, something like this:
> 
>  (myReadStrategy minimumDepth: 1)
>    forVariableNamed: 'dungeon' onAny: Player readToDepth: 1 ;
>    forVariableNamed: 'desk' onAny: Dungeon readToDepth: 1 ;
>    forVariableNamed: 'letters1' onAny: Desk readToDepth: 2 ;
>    forVariableNamed: 'letters2' onAny: Desk readToDepth: 2.
> 
> This will cause the Player-->Dungeon-->Desk-->OC of Letters to be
> grabbed in a single server-trip.
> 
> The 'letters1' OC species 2 levels because there is the intermediate
> 'array' variable..  But you'll have to experiment to get it fully
> optimised.  The way to do this is be careful opening inspectors,
> because clicking the instVars inspectors invokes #printString causes
> proxy materializations.  So what you do is just open the *inspector*
> (NOT an explorer) on your Desk and ask the instVar for its class
> before inspecting it:
> 
>  letters1 class   "MagmaMutatingProxy"
> 
> then you know you need one level deeper, because you want it to say
> "OrderedCollection".  When you fix the ReadStrategy to do that, try it
> again but still do NOT click on the 'letters1' variable because the
> inspector will try to enumerate the values.  Instead:
> 
>  letters1 basicInspect
> 
> and then, in the basic-inspector:
> 
>  array class   "Array" or "MagmaMutatingProxy"
> 
> and so on.
> 
> In this way you can see exactly how it works and, knowing what you
> need, be able to craft a fully-optimised ReadStrategy for each
> use-case.
> 
> Regards,
>  Chris
> 
> On 6/14/07, Florian Minjat <florian.minjat at emn.fr> wrote:
>> Hi Chris,
>> I read the ReadStrategy FAQ and it's quite interresting. I have some
>> question though.
>> First of all, how long will the read strategy last for a given session
>> by doing mySession 'session readStrategy: myReadStrategy.' ? Do I have
>> to revert it back to a default strategy after my specific queries ?
>> Then is it possible to be more specific. For example : my Players have
>> a reference to a Dungeon which references a Desk which has two
>> OrderedCollection referencing Letters. If I want to send a Letter to
>> 10 Players, I need to had a Letter in each of their Desk, resulting of
>> a huge query I think. Is there a way to be so much specific with a
>> ReadStrategy ?
>> By doing such a query, my understanding is that the other referenced
>> objects of the Dungeons won't be materialized. Am I right ?
>>
>> Florian
>>
>> Florian Minjat wrote:
>> > Great ! I knew there were already something like that in Magma.
>> > I will test it soon. It should speed up the listing of the players
>> > considerably.
>> > Thanks !
>> >
>> > Florian
>> >
>> > Chris Muller wrote:
>> >> Yes, I think you are asking about ReadStrategy's.  They are crucial to
>> >> getting proper performance out of Magma.  Here is the information
>> >> about ReadStrategy's you must understand:
>> >>
>> >>  http://wiki.squeak.org/squeak/2638
>> >>
>> >>
>> >> On 6/12/07, Florian Minjat <florian.minjat at emn.fr> wrote:
>> >>> I have another question : if I ask magma for an object Player which
>> >>> references others Players in its Letters, will magma deserialize all
>> >>> the referenced players ?
>> >>> If it is the case, is there a way to ask for an 'half-deserialization'
>> >>> ? By that I mean for example getting the referenced Players with all
>> >>> their primitive objects but no referenced object ? Otherwise I will
>> >>> need to seriously rethink the Mailbox/Letter model of my application.
>> >>>
>> >>> Florian
>> >>>
>> >>>
>> >>> Chris Muller wrote:
>> >>> > Hi Florian, this is an interesting problem.
>> >>> >
>> >>> > First to answer your question, Magma identifies an object as already
>> >>> > in the repository if it has a "permanent" oid.  This is an oid range
>> >>> > between MaOidCalculator #firstUserObjectOid and #lastUserObjectOid.
>> >>> > The #hash of an object never comes into play to determine this, or
>> >>> > anything in Magma for that matter.
>> >>> >
>> >>> > One way to get your large object-model into Magma would be to change
>> >>> > the method MaObjectBuffer>>#ensureSpaceFor: to allow more than 10
>> >>> > megabyte serializations.  I only suggest this only because it is an
>> >>> > arbitrary limit and it looks like your model is right there just 
>> over
>> >>> > the limit.  Change it to 50-meg on the fastest computer you have, It
>> >>> > should work.  Submit the commit and let it run all night.
>> >>> >
>> >>> > Another option would be to temporarily change your Players to
>> >>> > reference the other players only logically; by some temporary id or
>> >>> > something.  Once you get them loaded into Magma, then reset the
>> >>> > references back to the actual objects.
>> >>> >
>> >>> > Note #maTransientVariables is available to implement on Player so it
>> >>> > will not serialize those variables, so you could actually ADD a new
>> >>> > logical reference, if necessary, and make the hard player reference
>> >>> > transient (temporarily).
>> >>> >
>> >>> > Please let me know if these ideas are feasible.
>> >>> >
>> >>> > - Chris
>> >>> >
>> >>> >
>> >>> > On 6/10/07, Florian Minjat <florian.minjat at emn.fr> wrote:
>> >>> >> Hi,
>> >>> >>    I am trying to transfer a big object hierarchy to Magma : 110100
>> >>> >> objects in 9004144 bytes.
>> >>> >>    The basic structure is composed of ~70 Players with a lot of 
>> stuff
>> >>> >> inside. Each players can have some Letters which references other
>> >>> >> Players as sender or recipients.
>> >>> >>    The problem is that I can't submit one player to an empty Magma
>> >>> >> repository without letting Magma insert all the references Players.
>> >>> >> And the resulting transaction is too big, causing an error. So I
>> >>> >> separated all the Letters from the Players, inserted the players
>> >>> >> (~50min) and then tried to insert the Letters. But I close the
>> >>> >> connection to the magma repository between the two, so Magma tried
>> >>> >> again to load all the references Players.
>> >>> >>    So here is my question : how does Magma identify a given 
>> object as
>> >>> >> already inside a repository ? Does it compare the hash of the 
>> objects
>> >>> >> and I just need to redefine the hash method of Players ?
>> >>> >>    Each try is quite long so I would like to understand a little 
>> more
>> >>> >> of the inner mechanisms of Magma instead of trying numerous times.
>> >>> >>
>> >>> >> Florian
>> >>> >> _______________________________________________
>> >>> >> Magma mailing list
>> >>> >> Magma at lists.squeakfoundation.org
>> >>> >> http://lists.squeakfoundation.org/mailman/listinfo/magma
>> >>> >>
>> >>> >
>> >>> _______________________________________________
>> >>> Magma mailing list
>> >>> Magma at lists.squeakfoundation.org
>> >>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>> >>>
>> >>
>> > _______________________________________________
>> > Magma mailing list
>> > Magma at lists.squeakfoundation.org
>> > http://lists.squeakfoundation.org/mailman/listinfo/magma
>> >
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>
>

More information about the Magma mailing list