Magma November 2007

magma@lists.squeakfoundation.org

10 participants
11 discussions

Tutorial
by Keith Hodges 15 Dec '07

15 Dec '07

There have been calls for a Magma tutorial to go into the Seaside tutorial in the persistency chapter. This chapter already includes Glorp and GOODS. Just in case someone is already, or thinking of doing this, I have already written such a mini tutorial. In order to make Magma even easier to use, I have begun rewriting "Magma seaside" to take advantage of my new Seaside Session Helpers interface, which I released yesterday. The idea being that you can now use Magma, without a specialized Seaside Session class. This should make it easier for users to adopt Magma for their existing applications. I am a little unsure as to how you are supposed to obtain an exact match of a unique item from the database. This is how I would do it (althought I know MagmaCollections dont actually implement #firstOrNil) ^ (self users where: [ :each | each email = anEmail ]) firstOrNil Is there a better way to obtain a unique value? cheers Keith p.s. the wiki page that I refer to on MagmaCollections is a bit out of date. ---- so far... *Saving all data in an object-oriented database: Magma* Another option to make your data persistent is to use an object-oriented database like Magma. *Installing the Magma Database* Magma is written entirely in Squeak, so there is no need to install a separate server application. Both Magma and Seaside can run in the same image. To install (into a 3.10 based image) just execute the following. (This may take a while) Installer universes install: 'Magma seasideHelper'. * Configuring your application to use Magma* In the configuration for the 'todo' application you will need to add WAMagmaConfiguration to the configuration "ancestry". Select it from the drop down menu and click "Add". As soon as you do this, a new group of configuration options will appear. You will need to select the "WAMagma", helper class from the drop down menu. The WAMagma class provides the basic interface between Magma Sessions and Seaside Sessions. Subclasses provide specialised session management such as shared or pooled sessions. *Using Magma* Magma is very easy to use with seaside. To obtain and use a database session helper, simply send #magma to the current session. For example the code "self session magma" will work within all seaside components. To use Magma in this application in a similar manner to the way we have connected to databases in other examples we need to create an interfacing class, to which we can add our specialized querying methods. Dictionary subclass: #StMagmaDatabase instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'STTutTodoApp' StSession-#initialize super initialize. self db: (self magma rootAs: StMagmaDatabase) The tutorial application accesses the database via the #db accessor. Here we define this using the #rootAs: helper method, which does everything we need, both to initialize the database, and to provide us the interface that we want to it. To initialize our users collection we define the initialization on our root object, and we need a method to return the users from the database, to add a new user, and to find a user. StMagmaDatabase-#initialize | users | users := OrderedCollection new. self at: #users put: users. StMagmaDatabase-#users ^ self at: #users StMagmaDatabase-#addUser: newUser ^ self users add: newUser StMagmaDatabase-#findUserByEmail: anEmail ^ self users detect: [:each | each email = anEmail] ifNone:[] Notice how for basic usage we have not needed any database specific code! If our userbase is going to grow to a significant size it makes sense to re implement the above using some database features, so we introduce a MagmaCollection which you can read about in detail here: http://wiki.squeak.org/squeak/2639 initialize | users | users := MagmaCollection new. users addIndex: (MaSearchStringIndex attribute: #userName) beAscii. users addIndex: (MaSearchStringIndex attribute: #email) beAscii. self at: #users put: users StMagmaDatabase-#users ^ self at: #users StMagmaDatabase-#addUser: newUser ^ self users add: newUser StMagmaDatabase-#findUserByEmail: anEmail ^ (self users where: [ :each | each email = anEmail ]) firstOrNil ... need to explain how committing works... etc

7 29

RE: Save and query dependent objects
by Carsten Karkola 27 Nov '07

27 Nov '07

Hi Sebastian, thank you for your suggestions. I've tried them out - storing the whole model starting with the top node. Beside that I created MagmaCollections to store objects for quick access via queries, as you suggested: > As far as I know nothing stops you to have in other part of the odb > the cars that also refers (have in its instVars) lots of those parts. That > way you won both: the easiness of having all the parts indexed in a magma > collection (usually the only efficient approach in the relational world) and > the conceptual model of it's position in the "car space". > Do I need some special code to ensure that the objects will not be saved twice? As far as I can see, if an object is part of another object (in its instVar) in a Magma DB and is put separately in a Magma Collection it will be stored only once. I can look for it via a query and change it or I can look for it traversing my domain model and change it there - so it seems that the object is really only once in the DB. In my test code it worked this way. I'm right with this? (I'm a little bit confused about this magic ... ). Thanks, carsten _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

2 1

DNU in persisted contexts and VM crashes
by Sebastian Sastre 24 Nov '07

24 Nov '07

Hi there, I'm experimenting systematical crashes of the VM complaining about primitive 195 lately. When calm down of the annoyance (and code recover) I was able to set up a halt previous to the crash in a Seaside application. Using setp by step, I've noticed that one context stored in the model stored in magma was being evaluated but the debugger was unable to show it's code properly. Still, the context seemed to be evaluating. Making little steps into it lead me to a does not understood exception. Also noticed that one of the temp vars of that context (t1) was in nil instead of the expected object. To provide a better idea of the scenario supose this: PersistedObjectModel>>materials materials ifNil:[self initializeMaterials]. PersistedObjectModel>>initializeMaterials ^ materials := self makeMaterials PersistedObjectModel>>makeMaterials ^Dictionary new at: #m1 put: (Material new costFunction: [:val| val * self moneyUnit]; yourself); at: #m1 put: (Material new costFunction: [:val| val * self moneyUnit]; yourself); yourself the PersistedObjectModel is stored in the root dictionary under some key. If I don't put that halt to follow it with the debugger the DNU never signals. It goes directly to the crash. Maybe the Seaside continuations are interfering for this temp var/signaling? So seemed to me that somehow Magma was having trouble to identify 'self' in the persisted context of the costFunction in those materials and letting that in nil causing a nil DNU #moneyUnit. So I've tried a workarround for this: don't make use of self in that context. Just use in the context things that can be deducted more independently of *that contextual situation*. So I've made the seaside session to call the persistedObjectModel like: costFunction:[:val| val * self session moneyUnit] (I've made all objects, even nil, to be able to answer the current seaside session) I'm not proud but so far I prevented that ugly situation, cheers, Sebastian Sastre PS1: take care when experimenting with this. I had to recover about 5 hours of work when the first crash occurred to me and 1 hour a second time. PS2: You will not experiment a crash if you create all in the image and then try to test in same instance-image. Instead, after the repository creation, quit Squeak and open it again. There you'll have the crash. I imagine that caches are securing things in the repository creator image.

1 0

Save and query dependent objects
by Carsten Karkola 22 Nov '07

22 Nov '07

Hi, I'm new to magma and I've read the docs in the swiki and browsed the magma tests to get a basic understanding how to work with it. In the FAQs I found an answer: "With the standard dependency mechanism, dependents are not directly connected, so they will not be persisted". What does this mean? Lets say I have some classes: Building Floor Room A Buidling has floors and floors have rooms. As far as I understand - if I save a building instance in magma, the assoicated floors and there rooms will also be saved. So I can get a building instance from magma and ask it for its children. But how do I look for a specific room in magma without traversing the whole tree structure starting at the building node. In a RDBMS I would query for the room - get the foreign key of the floor and so on. Or should I put all tree nodes (building, floor and room instances) in there own MagmaCollection to use them with a MagmaCollectionReader? What would be the best way to save such a tree like structure with the ability to query for one of the nodes and to get after that the parents of that node? The goal is not only to traverse the tree from top but also to answer questions like "What room has the user carsten and in which building can I find this room?". Thanks, Carsten _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

2 1

Persisting object from unknown class
by Hilaire Fernandes 22 Nov '07

22 Nov '07

Are there any preferred mechanism when persisting instances from unknown classes of the Magma server? Once I read code from Chris doing that: mySession codeBase fileOutClass: AClass Are there any automatic mechanism to do that automatically when persisting unknown instances classes? Thanks Hilaire

1 1

Removed major memory-inefficiency from MaHashIndex!
by Chris Muller 19 Nov '07

19 Nov '07

An "optimization" in MaHashIndex traded way too much memory consumption just to avoid two Array allocations for each query of a MaHashIndex. This is way not worth it. I strongly recommend installing/merging Ma special collections-cmm.85 from the "MagmaTester" project of squeaksource. This will be rolled into release 41, of course. - Chris

2 2

sessions not disconnected
by Ching de la Serna 18 Nov '07

18 Nov '07

Hi Magma, Should a MagmaSession not be disconnected propoerly, would this lead to sessions being accumulated leading to a memory leak? If so, how do I remove these sessions? Thanks in advance. Ching

2 1

maDeepCopy
by Keith Hodges 15 Nov '07

15 Nov '07

Daer Chris, fyi. Dictionary-maDeepCopy doesn't return the copy but the original best regards Keith

2 1

Re: Slow performance
by Todd Blanchard 12 Nov '07

12 Nov '07

I already need it badly. Even if the root collection isn't a MagmaSet - the first collection I want to add is. So why doesn't that work? Also, I've found that changing the root doesn't work. The change doesn't save. So I had to throw away the db and start over. On Nov 8, 2007, at 6:17 AM, Sebastian Sastre wrote: > ... > >> I want the root to act like a dictionary - so I set it up like this: >> >> | set | >> set := (MagmaSet equivalenceAttributes: (Array with: #key)). >> set addIndex: (MaSearchStringIndex attribute: #key). >> MagmaRepositoryController create: 'magma' root: set. >> > But Todd wait a minute, you're contradicting yourself. Why you want > to put in root aSet if you want it to behave like aDictionary? > > Frankly I would use a Btree in the root or even a plain Dictionary > like: > > MagmaRepositoryController create: 'magma' root: BTree new ...or > MagmaRepositoryController create: 'magma' root: Dictionary new > > They implements (more efficiently than a set of associations) > #at:put: message because is it's nature to do it and in the end you > seems to > be trying to reivent with the set of associations. > > Simple things will allow you to grow. Try not to get involved with > complexities until you really need it badly, > > cheers ! > > Sebastian >

3 2

Slow performance
by Todd Blanchard 10 Nov '07

10 Nov '07

I may be doing this wrong so I'll share my approach - I'm finding it unusably slow though. I'm working on a stock market analysis tool. There are about 1100 securities on the AMEX, NASDAQ, and NYSE. So I create a Dictionary in the root dict called securities. This is keyed by stock ticker symbol and the value is an object of type security which contains fields tickerSymbol, exchange, issueName, and historicalData. The historicalData is an OrderedCollection of quotes going back as far as the 80's. A quote is a timestamp, hi, low, close, and trade volume. There are around 300 of these per year - going back as much as 25 years. Believe it or not, I can fetch these from yahoo as a csv and process them into objects in about 5-10 seconds per security. Saving this data structure into magma seems to take many times that. Something like 3 hours in Magma I think. If this were just the initial load, it would be tolerable. However fetching the last 5 days quotes and splicing them onto the tail of the historicalData collection takes as long as the initial load. So this approach isn't working for me. I'm open to ideas on better ways to structure this. I'll also be adding some charts to keep in the database - the idea being the charts are mostly up to date and I only have to replot the last day's worth of data everytime it is fetched. When I say chart - I mean a data structure containing a 2D array of values - not a visual representation. I will always draw the visual form on the fly. This chart will also potentially be a big block of data that will reference the historicalData points. Ideas? I'm close to just going to image segments - one per security. -Todd

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma November 2007