Magma May 2010

magma@lists.squeakfoundation.org

6 participants
5 discussions

Ma object serialization
by Mariano Martinez Peck 30 May '10

30 May '10

Hi Chris. Is it possible to use the Ma object serialization outside Magma? I mean, I just need an object serializer (not magma). Can I use it? how ? do you have examples? which packages should I load? Do you know the performance in compare to SmartRefStream for example ? Thanks a lot in advance, Mariano

2 1

Collections issue
by Facundo Vozzi 17 May '10

17 May '10

Hi, I'm using Magma r42 on Pharo 1.0 and I have this situation: "2356 Cities" Time millisecondsToRun: [mySession root states first cities do: [:each | Transcript show: each]] "16178 milliseconds" mySession root answer a singleton that have 23 states and the first state has 2356 cities. Is 16178 milliseconds the expected time for accessing to it? states and cities are OrderedCollection instances. Must I change it to MagmaCollection for better performance? Thanks, Facundo

3 4

Re: Collections issue
by Facundo Vozzi 17 May '10

17 May '10

Hi Balázs, > Was the Transcript open? Because #show: is dog slow. > For me it takes some minutes to write 2356 things to the Transcript. > Yes I know that but in this case a put show: for force instances materialization because I need the name instance variable initialized from the repository. Only for information these are my show: times, "Closed transcript" Time millisecondsToRun: [ 1 to: 2356 do: [:each | Transcript show: 'String', each asString]] "10818 milliseconds" "Open transcript" Time millisecondsToRun: [ 1 to: 2356 do: [:each | Transcript show: 'String', each asString]] "117107 milliseconds" Facundo

1 0

Re: Collections issue
by Facundo Vozzi 17 May '10

17 May '10

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

1 0

Re: Hosting website with MagmaDB on Seasidehosting
by Damion Mitchell 06 May '10

06 May '10

I am a newbie to Magma, and I am working on a project and I was wondering if there is an easy way to configure my system to have Magma work on seasidehosting. Now it is presently working on my local machine *connect* * **session := (MagmaSession openLocal: 'PackageDB') newSession; connectAs: 'admin'.* * * I would appreciate if some assistance could be given in this regard. Now I have implemented somewhat of a Singleton pattern, where I am allowing one DBase Connection per user session. Now I am having two issues. 1. How can I explicitly save the changes made to actual MagmaDB. As I can store data, to the object while in memory, but if I close the image all those changes are lost. So how can I ensure that it is also stored in the localfile. 2. I have an #unregistered method, however sometimes it works fine and another time is complains that is doesNotUnderstand disconnect. Any hint or solution as to why this might be happening *initialize * * **super initialize.* * **self database: PTDatabase new.* *unregistered* * ** **self database session disconnect.* * ** **super unregistered.* * * *Thanks in advance.* -- Damion Mitchell

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma May 2010