Object identity

Chris Muller asqueaker at gmail.com
Fri Jun 15 04:21:43 UTC 2007 

> 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