Magma December 2010

magma@lists.squeakfoundation.org

10 participants
13 discussions

Can't access objects in dictionary
by Amir Ansari 31 Dec '10

31 Dec '10

I enter the following code in a Workspace: (the class 'User' is just a very simple class with instance variable 'username' and corresponding accessors) MagmaRepositoryController create: '/testDB' root: Dictionary new. initialSession := MagmaSession openLocal: '/testDB'. initialSession connectAs: 'admin'. initialSession commit: [ initialSession root at: 'users' put: MagmaPreallocatedDictionary new ]. initialSession disconnect; closeRepository. newUser := User new username: 'Charlie'; yourself. newSession := MagmaSession openLocal: '/testDB'. newSession connectAs: 'charlie'. newSession commit: [ (newSession root at: 'users') at: newUser put: OrderedCollection new ]. newSession disconnect; closeRepository. testSession := MagmaSession openLocal: '/testDB'. testSession connectAs: 'aUser'. (testSession root at: 'users') size (testSession root at: 'users') at: newUser The last two lines indicate the problem: the size of the MagmaPreallocatedDictionary is reported correctly (even when I add more users), but when I try to access any of the entries with the 'User' objects as keys, I get a 'errorKeyNotFound:' error. Am I doing something wrong...? Amir

3 5

Re: Can't access objects in dictionary
by Amir Ansari 31 Dec '10

31 Dec '10

Hi Tim I'm using the User object as a key precisely because it's unique! Usernames will inevitably overlap. I considered email addresses, but if a user on the system changes their email address, it's an extra operation to update the Dictionary; with the User object, everything remains the same. Nevertheless, thanks for your reply! ;-) Amir On Thu, 30 Dec 2010 10:22:59 -0800 Tim Ziebart <timothy(a)churchmilitant.org> wrote: > I don't understand what you are trying to accomplish. I would have > expected the key to be a unique identifier such as username, email etc. > Then you would associate with the key a newUser. So, (newSession root > at: 'users') at: 'Charlie' put: newUser.

1 0

About MagmaPreallocatedDictionary
by Chris Muller 20 Dec '10

20 Dec '10

It is important to understand the nuances of using a MagmaPreallocatedDictionary. I must admit I intended it only for myself at the time I wrote it under a tight time-constraint; and so did not have time to develop what I really wanted.. Note the adjective, "Preallocated", it means all the hash-slots of the Dictionary are pre-allocated. This dictionary will not grow anymore. So this means there is a cap to how large it will scale before collisions are inevitable, which would rapidly degrade performance. Thankfully, the size of the support file on disk is actually only as large as needs to be to accommodate the *highest-used* hash value. Still, you will want to assume the highest-possible hash value could be used. It's 6-bytes per object-pointer so the file is 6 * [highest-used-hash-value] bytes in size. This makes the file on the server a many megabytes right out of the gate, but it won't grow again until a higher hash is used. It is absolutely _essential_ that you do not allow any identityHash to be part of your hash-calculation. Otherwise, it won't work; identityHash'es are unique between image sessions. Ultimately, MagmaPreallocatedDictionary will be deprecated. I would like to replace it with a new-and-improved MagmaDictionary based on the same concept (employing an underlying MagmaArray), but with a better hashing algorithm that allows expansion without rehashing the elements. - Chris

2 1

Report: upgrade to 1.2alpha and MagmaPreallocatedDictionary
by Timothy James Ziebart 16 Dec '10

16 Dec '10

Hi All, I wanted to let everyone know how it went. Environment: Linux Ubuntu 10.10, Seaside 3.0.2, Pharo 1.1.1. Monticello has not been updated with the latest Magma so I used the instructions Chris gave for loading the packages. I duplicated the list as follows: First load WeakOrderedCollection.2.cs.gz included on email from Chris announcing release of Magma 1.2 alpha1 - November 11, 2010. Ma exception handling-cmm.37 Ma base additions-cmm.187 Ma proxy support-cmm.44 Ma traverse object graphs-cmm.32 MaFixedWidthReport-cmm.7 Ma Statistics-cmm.24 Ma object serialization-cmm.245 Collections-BTree-lr.73 Ma special collections-cmm.116 Ma client server-cmm.217 WriteBarrier-cmm.28 Magma client-cmm.520 Ma contextual search-cmm.35 Magma server-cmm.418 Ma Armored Code-cmm.149 Ma Squeak domain-cmm.34 Ma special collections tester-cmm.14 Ma object serialization tester-cmm.33 Magma tester-cmm.372 Ran the upgrade on my existing database using instructions given by Chris in a previous email: please use the "Magma upgrader" package available on the "Magma tester" project of squeaksource. After loading it: (MagmaUpgrader source: '/path/to/old/repository') compressTo: '/path/to/upgraded/repository' Results: Packages loaded and upgrade went without a hitch. MagmaPreallocatedDictionary was then implemented replacing a standard dictionary keyed by region with each region holding a dictionary keyed by record id. My clients have to search a third party database with the results being updated with the data held in the magma database. The design was influenced by performance concerns. To reduce search time the client first selects a region and the dictionary associated with the region is loaded in effect loading only part of the database. The third party data is acquired and the records are then matched by a unique id on the dictionary now loaded. At this time there are only 30,000 region and record objects in the database (each object holds 10 fields containing strings and numbers totalling on average 200 characters). But with the standard dictionary loading the region dictionary took 7 seconds. After having implemented the MagmaPreallocatedDictionary the same operation takes LESS THAN A SECOND! The delay is imperceptible by the user. WOW, my next step is to test the performance by replacing the two tier dictionary to a single MagmaPreallocatedDicationary keyed on the record id. And thanks to Chris's comments I will be implementing a MagmaCollection on the same objects for performing descriptions and range searches. I must say I am impressed by Magma's reliability and the speed is not a factor -- the bottleneck is JQuery rendering! Thanks Chris. Tim

2 1

difference between MaDictionary and MagmaDictionary
by Esteban Lorenzano 15 Dec '10

15 Dec '10

Hi, I wonder what's the difference between MaDictionary and MagmaDictionary... and which should I use... is indistinct? Cheers, Esteban

5 13

MagmaRepositoryController error
by Amir Ansari 14 Dec '10

14 Dec '10

I'm getting an error trying to create a new repository; using Pharo 1.2beta (update 12272) and Magma 1.2alpha1, with WeakOrderedCollection. Workspace: "MagmaRepositoryController create: '/myDB' root: Dictionary new." Error: "Error: only integers should be used as indices" This certainly worked on Magma 1.1, but I was hoping to be able to use the new MagmaPreallocatedDictionary in 1.2... Should I post more detail about the error? Amir

2 2

Renaming persistent classes
by Chris Muller 13 Dec '10

13 Dec '10

>> Now I can proccess 1250 transactions from a csv file in less than 3 SECONDS >> including the time openning and proccessing of the file. Great! It's illustrative of the strengths of those two different parts of Magma. >> Other thing, after the refactoring I'm getting an error when I change >> anything on the class structure of any class. The error is: >> "MaObjectSerializationSoftwareError: Individual not defined in this image". >> That I did was rename two customer subclasses: >> Previous: >> Customer >> Individual >> Organization >> Now: >> Customer >> NaturalPerson (Persona Física) >> LegalPerson (Persona Jurídica) >> It's strange to me because now all seem works ok and because when I rename >> that classes haven't persistent instances on magma repository. >> >> Do you now that I'm doing wrong? Is it possible rename a persistent class? Yes, but you must do it under a transaction. Begin, rename, commit. If you didn't do it that way, then the repository will think it is just a new class and you will have to "upgrade" your old instances with a script. See MagmaTestCase>>testClassSchemaUpgrades. It includes a rename test. - Chris > The only person who can help you with this is Chris. Because my > knowledge about Magma in this area > are close to zero :) The other thing that can help everyone is the *code*. Answers to many questions are easily found there. It is straightforward, especially if you pay attention to the package each method is in; because that reveals what "layer" it operates on. - Chris

2 3

MagmaPreallocatedDictionary
by Facundo Vozzi 13 Dec '10

13 Dec '10

Hi Chris, list, how can I do to send #select: to a MagmaPreallocatedDictionary? Thanks, Facu

2 3

Re: Magma with style
by Facundo Vozzi 12 Dec '10

12 Dec '10

Now I'm getting a performance problem. I'm bulk loading transactions in sets (from a file) of 1250. Each of one has references to 3 objects, 3 numbers and 2 dates. When I test it without setting the customer it take to me 614 milliseconds to create the 1250 instances but if I look up for each client according to the client code it take to me 204158 milliseconds (3.40 minutes). Customers is a MagmaCollection and this is the method of the message that I'm sending 1250 times: customerAtDocumentNumber: unString sex: otroString "Devuelve un invividuo o una organizacion dependiendo de si unString corresponde a un número de documento o a un número de cuit. NOTA: se debe tener en cuenta el sexo por existir números de dni repetidos entre varones y mujeres." | aFewCustomers | aFewCustomers := self customers where: [ :each | (each documentNumber = unString)]. ^customers detect: [:each | each documentNumber = unString and: [each sex = otroString]] ifNone: [] Customers has an index on documentNumber. Now I go to profile it but I need to find how to do it in Pharo. I thing that I can switch customers from MagmaCollection to MagmaDictionary and set the document number + sex how the key. What do you think? See you, Facu On Thu, Dec 9, 2010 at 7:36 PM, Facundo Vozzi <facundov79(a)gmail.com> wrote: > >> >> If you do a copy, then you will be creating multiple instances of >> various "system entities", which I'm guessing don't want to do; you >> would rather have just one instance, referenced from multiple >> transactions, right? >> > > Yes, you're right I don't want multiple instances. > >> >> So all you need to do is just look-up the *equivalent* Code in session >> which is doing the loading. It will be the one identical instance in >> the repository. >> > > Yes, to do that I'm passing the session which is doing the loading by > argument. But I think that my error here is that I'm implementing the > protocol to get one entitiy instance by code or name on the Entity class > side. I think is > better implement it, by example #clientOfCode: aCode, in my system instance > which is the root of each session. In this manner I don't need pass the > user session by argument. I think that my traditional database mapping > thinking betrayed me > > >> But yes, this is one of the use-cases for which FP's were invented, it >> can be a more elegant solution, especially if the number of Codes is >> always changing or increasing. See >> MagmaTestCase>>#testForwardingProxy. >> > > Yes, I will see it right now. > > Facu > > >> >> - Chris >> >> >> > Thanks for your help, >> > Facu >> > >> > On Thu, Dec 9, 2010 at 4:35 PM, Chris Muller <asqueaker(a)gmail.com> >> wrote: >> >> >> >> I'm not sure I fully understand the context, but a third option might >> >> be to use ForwardingProxies. Especially if the shared objects can be >> >> updated by only one session (like a batch updater, for example). Then >> >> every other (user client) session will share the same instances in >> >> memory. >> >> >> >> HTH, >> >> Chris >> >> >> >> On Wed, Dec 8, 2010 at 1:13 PM, Facundo Vozzi <facundov79(a)gmail.com> >> >> wrote: >> >> > Hi all, >> >> > I'm refactoring my code and I found that I have two ways to do the >> same >> >> > in >> >> > distint parts of my system. >> >> > 1) Entity class >> atCode: aCode >> >> > "Answer the receiver instance with code equal to aCode or evaluate >> >> > aBlock if >> >> > it doesn't exists." >> >> > ^(self all detect: [:one | one code = aCode]) copy >> >> > or >> >> > 2) Entity class>> atCode: aCode inSession: anUserSession >> >> > "Answer the receiver instance with code equal to aCode or evaluate >> >> > aBlock if >> >> > it doesn't exists." >> >> > >> >> > ^(self allInSession: anUserSession) detect: [:one | one code = >> >> > aCode] >> >> > The difference is that 1 is using the shared session so I need copy >> the >> >> > object to be used (referenced by other object) on anUserSession. The >> >> > uggly >> >> > of 2 is that I have to pass anUserSession as argument. >> >> > Either way works well, is really the same? >> >> > Thanks in advance, >> >> > Facu >> >> > (*) I eliminate aBlock for absent elements for this example >> >> > _______________________________________________ >> >> > Magma mailing list >> >> > Magma(a)lists.squeakfoundation.org >> >> > http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> > >> >> > >> > >> > >> > >

3 8

Magma with style
by Facundo Vozzi 09 Dec '10

09 Dec '10

Hi all, I'm refactoring my code and I found that I have two ways to do the same in distint parts of my system. 1) Entity class >> atCode: aCode "Answer the receiver instance with code equal to aCode or evaluate aBlock if it doesn't exists." ^(self all detect: [:one | one code = aCode]) copy or 2) Entity class>> atCode: aCode inSession: anUserSession "Answer the receiver instance with code equal to aCode or evaluate aBlock if it doesn't exists." ^(self allInSession: anUserSession) detect: [:one | one code = aCode] The difference is that 1 is using the shared session so I need copy the object to be used (referenced by other object) on anUserSession. The uggly of 2 is that I have to pass anUserSession as argument. Either way works well, is really the same? Thanks in advance, Facu (*) I eliminate aBlock for absent elements for this example

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma December 2010