Collections issue

Facundo Vozzi facundov79 at gmail.com
Mon May 17 14:54:05 UTC 2010


Hi Brent,

Hi Facundo,
>
> I recommend you think in terms of "poxy agitation" and "materialisation" to
> understand how a _transparent_ database works.
>
> 01. When you evaluate "mySession root" there is a rount-trip to the Magma
> server get the root object.
> 02. This then gets materialised if it it not already in the image.
> 03. All the root object's instance variables are proxies.
> 04. When you send #states, you agitate the proxy in the 'state' instance
> variable.
> 05. The proxy fetches the OrderedCollection and all 50 states (but not
> their instance variables).
> 06. These are materialised and the proxy replaced.
> 07. When you send first, the newly materialised OrderedCollection responds
> immediately.
> 08. When you send #cities, you agistate the proxy in the 'cities' instance
> variable.
> 09. The proxy fetches the OrderedCollection and all 2356 cities (but not
> their instance variables).
> 10. These are materialised and the proxy replaced.
> 11. When you send #do: it is executed by the OrderedCollection immediately.
> 12. The #do: sends #value: to the block passing the first City instance.
> 13. The blocks sends #printString, via #show: to the City.
> 14. Assuming the #printString prints the city's name, the name instance
> variable is agitated.
> 15. The proxy fetches the name String and materialised it.
> 16. The city is shown on the Transcript.
> 17. Repeat 13-17 another 2355 times.
>

Yes, I read magma wiki documentations but your explication is very clear,
thanks.


>
> So,
> a) Large OrderedCollections are slow becuase the entire OrderedCollection
> is materialised,
>    even if you only want the first State.
>
> b) Consider MagmaCollections to fetch a State by name:
>    ca = session root state where: [ :s | s name = 'California' ].
>
> b) Materialisation of complex graphs of real Smalltalk objects is much
> slower than reading a
>    row of primitive types from an SQL table. Alas.
>
> c) You can minimise materialisation round-trips by using a ReadStrategy.
> For example, a City
>   should _always_ materialise its 'name' instance variable whenever a City
> is materialised.
>

I think that In this case c is the better option because I need a drop down
with states and when the user choice one of them I need other drop down with
its cities. Do you agree ?


>
> Respond to the list if you need more help.
>

Thanks you,

Facundo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20100517/6a0130af/attachment.htm


More information about the Magma mailing list