MagmaCollection API

[goran at krampe.se]

Hi Chris!

Chris Muller <chris at funkyobjects.org> wrote:
> Before, #read:at: that was on MagmaCollection and returned a reader;
> 
>  	| reader |
>  	reader _ cases read: #id at: id.
>  	reader size > 1 ifTrue: [self error: 'Multiple objects with the same
>  UUID!'].
>  	^reader size = 1 ifTrue: [reader at: 1] ifFalse: [nil]
> 
> so you still had to do the size checking, nothing has changed w.r.t.

Yes.

> that.  The only difference is now we have just one #where: method for
> all querying rather than multiple methods.  Everyone is concerned with
> code bloat, so I think #where: handling all cases was addition by
> subtraction.

Right, I just wanted to be sure that I haven't missed something
regarding the "proper" way of doing it. :)
 
> The other thing to watch out for with the above code is, because the
> reader is based on a collection that is always changing, its really
> best to use #at:ifOutOfBounds: since, theoretically, another user could
> remove objects causing the size to change.

Mmmm, ok.

> > PS. I am now experimenting with a shared magma session in combination
> > with one per user - I drowned in too much materialization otherwise.
> 
> By "otherwise", do you mean the strict 1:1?  And even after employing
> correct read-strategys?

Thing is I probably need "in memory" speed when viewing and filtering
the case collection. Some of my filtering can be done using indexing,
but some probably will need "iteration". So I will most probably end up
materializing all cases on a pretty regular basis. Doing that for 100
cases is probably no big deal, but 15000? Nope. Also - what I have seen
so far it takes a bit too long to materialize 20 cases in order to show
them in a table. Sure, a better readstrategy that only fetches exactly
what I need would help - but it is hard for me to predict what columns
(attributes) will be shown and how much state I need to fetch in order
to satisfy that - the columns are not hard coded.

So I simply need for Gjallar to "cache" the cases in RAM. I can't do
that for each and every user - so a shared session is the answer. The
"problem" with this approach is to know when I can abort it to get it
refreshed since the objects read using that session will be accessed
(readonly) by multiple Squeak Processes. I think I will just "ignore"
the issue for now and consider the model "thread safe" when used
readonly. Of course, Magma probably puts the objects in theoretically
unsound states for short periods of time when doing the refresh - but
whatever. :) If this turns out to be a problem I will just have to
protect the model with a Monitor while doing the abort.

Also, I have been toying a bit with readstrategies - only a tiny bit -
but I actually have a few questions regarding those:

0. You need to update the page http://minnow.cc.gatech.edu/squeak/2638
so that it says MaReadStrategy. :)

1. Am I meant to create a MaReadStrategy (say "MaReadStrategy
minimumDepth: 1"), configure it using
#forVariableNamed:onAny:readToDepth: (several of those messages of
course) and then put it in the session? If so - for how long is this
strategy valid? For the life of the session? Or just for the next query?

2. Let's say I use one strategy to read "just enough" of the Q2Case
instances when making queries over the collection. Then when I need to
view a *selected* case - I typically need to get "most of the rest" of
the case - a new strategy. But... this creates two more questions:

	2.1 If the case is already materialized - how can I control the reading
of the rest - can I somehow make sure it reads "the rest" in a single
materialization? Like, change the strategy in the session and then
perhaps run "session rematerialize: myCase" and then it would fetch the
stuff that is still missing using the new strategy?

	2.2 If I am running locally (no network roundtrips for each
materialization) do I still benefit from turning this into a single
materialization or does it not matter? This I can of course test - *if*
I knew how to do rematerialization using a different strategy.

Regarding #1 above, it puzzled me because I configured it when I created
the session but it appeared to "not work" - I was profiling and clearly
saw materializations where I would not expect them given the strategy.

In fact - it would be great if I could easily log materializations - I
will try to hook into that method you mentioned earlier.

regards, Göran