Magma October 2007

magma@lists.squeakfoundation.org

7 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

Blocking queries?
by Sebastian Sastre 01 Nov '07

01 Nov '07

Hi there, I saw some strange result when I use some code like this: someMagmaCollection where:[:reader| reader read: #companyName to:'ZZZ'] distinct: true sortBy: #companyName descending: false. then the result of that is used like: queryResult copyFrom: firstDesiredItemOfResult to: lastDesiredItemOfResult this last message is returning instantaneusly an empty array when in fact should not be empty. And seems to be only for the first send because if I resend the message, for instance manually in the debugger, I do get the right results for the next N (re)sends. How is expected to reach the result when you ask for it waiting for it if necessary? cheers, Sebastian Sastre

2 1

[ANN] New 'Magma seasideHelper' documentation
by Keith Hodges 30 Oct '07

30 Oct '07

Here is a first shot of the design docs before I post them pubically. I would be grateful of any feedback. I am still not sure how best to support MockMagmaCollections.Here I suggest that they always be contained in an object. Is there a way of using a genuine MagmaCollection as a Mock, such that readers and so on work even though there is no database behind? The package will be in MagmaTester, and it requires Seaside28Jetsam as well as Magma. cheers Keith ====== *Overview *The aim of this version of the Magma-seaside integration framework is to learn some lessons from projects already using Magma in order to satisfy the following goals. The overriding goal was to make the tutorial very easy, so as to blow away the competition! *1. Simplify Configuration. * *2. Enable Magma as a Helper*. Ease combining Magma with other seaside technologies, to which end we no longer subclass WASession. *3. Session Management Choice*. Provide options such as shared or pooled sessions again orthogonal to the domain, or other settings. *4a. Facilitate Modularization.* Provide the framwork to allow a Magma user-accounts module to be deployed as a plug-in package, combinable with other modules, such as a pier module, or a shopping-cart module. *4b. Similarly, Facilitate Project Combination.* Projects having separate databases may merge into one, e.g. gjallar & pier. *5. Simplify Use and Initialization.* Initialization of models, not just of the root object, but also sub-branches of the database which are used by different application-modules or application sub-domains. *6. Server Managed Preferences.* Server to client propagation of preferences and data for multi-server operation, and load sharing schemes. *7. Direct Usage Outside of Seaside. *Aim to standardize the manner in which services, tests and other procedures access a database which is configured via seaside. ==== *1. Simplifying Configuration* The seaside configuration provides a selector for the database helper class which provides session management. You can provide your own scheme by subclassing any of the WAMagma helper classes. The local database directory, is initially set to 'Automatic' which will save the data in 'magma-todo' directory for the 'todo' entry point. This ensures that by default no configuration is required while at the same time separate applications will not step on each others' databases files. *2. Enable Magma as a Helper* In order for Magma to be used alongside other frameworks which have specialized session classes such as Glorp, the configuration of Magma is now orthogonal to the choice of WASession. You may subclass WASession if you need to, in order to support your application domain, but it is not necessary to do so either to use Magma, or to store session state. Session state can now be stored using the WASession-#properties dictionary. This is accomplished through the WASessionHelper framework which is part of Seaside28Jetsam. Magma is supported by one such helper and the chosen Magma helper is accessed via WASession-#magma. Instanciation. Magma helpers provide session management, options include: single - WAMagma shared - WAMagmaShared pooled - WAMagmaPooled mock - WAMockMagma *4. Facilitate Modularization.* Modularization requires the objects in the database to manage their own behaviour. Rather than fill the database with generic containers such as Dictionaries and MagmaCollections without any specialization, we should recommend subclassing and specializing the typical model container objects. The base classes would be WADictionaryRoot, Object or MagmaCollection. However it is as well to point out that subclassing MagmaCollection directly lands us with a significant limitation. It prevents us from easily switching all MagmaCollections for MockMagmaCollections! To make this switching ability transparent the class WAMagmaCollection is provided as a base class to use for specialization instead. By default it contains a MagmaCollection (or a MockMagmaCollection) and you can also add slots to persist your favorite reader queries defined on initialization. This approach also guarantees that the model has a place to put these query optimizations should you need them. For example, to define an application specific model "ToDoList" for your database, subclass WADatabaseRoot (which is an IdentityDictionary) and define your custom accessors on that class e.g. ToDoList-#items ^ self at: #items ToDoList-#users ^ self at: #users If #items is a subclass of WAMagmaCollection called TodoListItemsCollection then you can define your custom item based queries on your own subclass of WAMagmaCollection, encouraging typical object-oriented encapsulation. itemsForUser: name self where: [ :each | each usersName equals: name ] On your domain objects or components, access your database like so: MyComponent-todoListDatabase ^ self session magma rootAs: ToDoList and... MyComponent-todoListItems ^ self todoListDatabase items However for a sub-domain or module model you can also do. MyComponent-todoListItems ^ self session magma rootAs: TodoListItemsCollection This means that the sub-domain or module models can be referenced by the domain irrespective of their place in the actual database structure, which is defined in your specialized model classes. They know where in the database they are located, and importantly they know how to initialize themselves. This scheme allows several applications or modules to be layered upon a single database. Each model class can nominate its own personal root object in the main database which is returned via the rootAs: idiom (see class methods #getVirtualRootIn: #initializeVirtualRootIn: etc) It also allows the database to be re-organised by changing model classes only. The domains view of the database is decoupled from the modular structure of the database. *5. Simplify Use and Initialization. *Initialization is performed automatically as far as is possible. When using the standard accessing idiom: 'self session magma rootAs: MyModel'. If this is performed and the database does not exist, or has no root class, then, the root will automatically be initialized according to the #actualRootClass nominated by the model class. This makes databases auto-initializing. If the virtualRoot model object for MyModel itself is not present in the database, then it will also be initialized automatically. The initialized root or model-objects are configured, and indexes added if needed, in their respective #initialize methods. If a model is retrieved that is not of the correct class, #rootAs: attempts to mutate the instance into the desired class, thus providing some automatic schema migration at the module level. *6. Server Managed Preferences. *An optional module which allows a seaside-server-magma-client application to pick up settings and preferences from the magma-server. Whenever a new seaside session is started, on the first time only, the root object's #firstRead: method can call 'helper rootAs: WAServerManagedPreferences'. WAServerManagedPreferences is implemented as a module, being as self contained as possible to demonstrate the principles outlines above. It assumes the root object of the database is a dictionary (if not it will need to be reconfigured appropriately). This module, when #firstRead:, checks its #expiry time, and if it has expired, it loads the current application's preferences with the values that it contains. The values are each sent #value before being written. This would allow #location to return a version of MagmaRemoteLocation which when sent #value, evaluates picking a remote server based upon the client's identity. This scheme would enable seaside-server-magma-client to be deployed, the first time anyone accesses the server it would obtain its new settings and potentially redirect to a new server. *7. Direct Usage Outside of Seaside * Standardize the manner in which services, tests and other procedures access a database which is configured via seaside. WAMagma helper may be used with Seaside, or directly. Configuration is per-seaside application e.g. (WAMagma forApp: 'todo') location. (WAMagma forApp: 'todo') readStrategyClass. (WAMagma forApp: 'todo') areMaterializationNotificationsEnabled. (WAMagma forApp: 'todo') commit: [] etc.

2 1

becomeForward:
by Keith Hodges 30 Oct '07

30 Oct '07

Hi Chris, Does magma cope if an object in the tree is mutated into an instance of another class via becomeForward: ? Keith

2 1

Saving big objects?
by Sebastian Sastre 24 Oct '07

24 Oct '07

Hi Chris, all, I've been reading some Gjallar code to see how they use Magma. I saw the a main object which is tha application model and it has 4 or 5 MagmaCollections in it's instVars. So I in a load test I've made a model object with a magma collection with 10000 person objects. It performed nicely. Then I pushed that by making this person object to store in one of it's instVars #acts and set up there a magma collection and added 20 acts objects to every person. So it should end up with 10K persons having one magma collection with 20 act objects each. What I've got is a serializer security exception MaObjectSerializationSecurityViolation saying that one can't serialize objects of more than 10 megabytes. I've read about starting small with Magma but I need a glimpse on how the model I'm thinking on support with Magma will scale. From this test it seems that Magma collections supports lots of objects but any common object suporting even a low number of magma collections that will be growing will easily reach more that 10 megabytes when serialized. So I'm missing something? There is a more appropiate use of Magma for a model like that? Same question in other scenario: the main object of the domain model the root of the application domain from where all is accessed by reachability will also suffer this limitation. What one can do at that point? thanks, Sebastian Sastre

2 3

RE: Saving big objects?
by Sebastian Sastre 22 Oct '07

22 Oct '07

Indeed Igor! I was making the test in an unrealistic fashion from the application magma usability point of view. Thanks a lot for the clue. Now I've made a test comiting first the model in some root's key and then adding sample objects to it comitin changes from time to time. Magma behaves well until the image goes bigger than 200 megabytes in ram. cheers, Sebstian > -----Mensaje original----- > De: Igor Stasenko [mailto:siguctua@gmail.com] > Enviado el: Sábado, 20 de Octubre de 2007 09:05 > Para: Sebastian Sastre > Asunto: Re: Saving big objects? > > I think, the answer is to not put too many data in single transaction. > Simply divide your model populating on smaller stages and > everything should be just fine. > Like: > > session commit: [ "add fisrt 1000 objects"]. > session commit: [ "add second 1000 objects" ]. > .... > > > On 20/10/2007, Sebastian Sastre <ssastre(a)seaswork.com> wrote: > > > > > > Hi Chris, all, > > > > I've been reading some Gjallar code to see how they use > Magma. I > > saw the a main object which is tha application model and it > has 4 or 5 > > MagmaCollections in it's instVars. > > > > So I in a load test I've made a model object with a magma > > collection with 10000 person objects. It performed nicely. > > > > Then I pushed that by making this person object to > store in one of > > it's instVars #acts and set up there a magma collection and > added 20 > > acts objects to every person. So it should end up with 10K persons > > having one magma collection with 20 act objects each. > > > > What I've got is a serializer security exception > > MaObjectSerializationSecurityViolation saying that one > can't serialize > > objects of more than 10 megabytes. > > > > I've read about starting small with Magma but I need a > glimpse on > > how the model I'm thinking on support with Magma will > scale. From this > > test it seems that Magma collections supports lots of > objects but any > > common object suporting even a low number of magma collections that > > will be growing will easily reach more that 10 megabytes when > > serialized. So I'm missing something? There is a more > appropiate use of Magma for a model like that? > > > > Same question in other scenario: the main object of the domain > > model the root of the application domain from where all is > accessed by > > reachability will also suffer this limitation. What one can > do at that point? > > > > thanks, > > > > > > > > Sebastian Sastre > > > > > > > > > > > > > > _______________________________________________ > > Magma mailing list > > Magma(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > > > > > -- > Best regards, > Igor Stasenko AKA sig.

1 0

RV: Unable to connect to Magma server
by Sebastian Sastre 15 Oct '07

15 Oct '07

I intended to send it here (sorry Chris for the double mail) Sebastian > -----Mensaje original----- > De: Sebastian Sastre [mailto:ssastre@seaswork.com] > Enviado el: Lunes, 15 de Octubre de 2007 13:03 > Para: 'ma.chris.m(a)gmail.com' > Asunto: RE: Unable to connect to Magma server > > Ok this happens to me too but I think I have a clue. > I was testing locally in a windows system in the same image, > then saw the Todd's post about problem on connections. Then > tried to put a server in another host and use the windows > client. I have the same problem Todd's had: socket timeout. > > The server image I was trying to connect was in a copy of the > image (+ subdirs) that was previously working in windows in > an ubuntu box. > > The NetNameResolver localHostAddress in windows gives the lan > ip but in the linux it gives 127.0.0.1 > > I hope this help in diagnosys > > Sebastian Sastre > PS: I also guarantee in the tests that firewalls are not > intruducing noise here > > > > -----Mensaje original----- > > De: magma-bounces(a)lists.squeakfoundation.org > > [mailto:magma-bounces@lists.squeakfoundation.org] En nombre > de Chris > > Muller Enviado el: Viernes, 12 de Octubre de 2007 18:36 > > Para: Todd Blanchard > > CC: magma(a)lists.squeakfoundation.org > > Asunto: Re: Unable to connect to Magma server > > > > Your code looks fine, it should work. You might try print a > > NetNameResolver localHostAddress in your server image to > see what you > > get.. > > > > On 10/12/07, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > I'm on Mac OS X - running 2 VM's one for the server, one client. > > > > > > Server is setup, initialized, seems happy-ish. I'm using > > latest dev > > > image + magma server + BTree. > > > > > > MagmaRepositoryController create: 'magma' root: BTree new > > > (MagmaServerConsole new open: 'magma') processOn: 1010 > > > > > > Seems fine. > > > > > > Second image I try: > > > > > > | mySession | > > > mySession := MagmaSession > > > hostAddress: #(127 0 0 1) asByteArray > > > port: 1010. > > > mySession connectAs: 'magma'. > > > mySession > > > > > > and I get an error - connection timed out. Is there some > > kind of ping > > > I can send the server via telnet to see if it really is alive? > > > > > > > > > _______________________________________________ > > > Magma mailing list > > > Magma(a)lists.squeakfoundation.org > > > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > > > _______________________________________________ > > Magma mailing list > > Magma(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/magma

1 1

Unable to connect to Magma server
by Todd Blanchard 12 Oct '07

12 Oct '07

I'm on Mac OS X - running 2 VM's one for the server, one client. Server is setup, initialized, seems happy-ish. I'm using latest dev image + magma server + BTree. MagmaRepositoryController create: 'magma' root: BTree new (MagmaServerConsole new open: 'magma') processOn: 1010 Seems fine. Second image I try: | mySession | mySession := MagmaSession hostAddress: #(127 0 0 1) asByteArray port: 1010. mySession connectAs: 'magma'. mySession and I get an error - connection timed out. Is there some kind of ping I can send the server via telnet to see if it really is alive?

2 1

Evaluating Magma
by Sebastian Sastre 07 Oct '07

07 Oct '07

Hi there, I want to evaluate Magma as persistance solution for a project (on squeak and Seaside). I'm having trouble to install it. Tried from SqueakMap and then universes. It's saying me a message about Cache is defined elesewhere. I saw lots of packages in the squeak source repositories. I don't know how to start from there (its my favorite choice) cheers, Sebastian Sastre

2 2

new version r40 working like a charme, still issue when persisting TextMorph
by Hilaire Fernandes 06 Oct '07

06 Oct '07

I have been able to update data base to r40 from r39. Thanks Chris !! However I still need to change Magma method StrikeFont>>maAsStorageObject to correctly persist TextMorph (see my post the 16 of July, with a fix) Does anyone else got problem when persisting TextMorph? Well may be few of you persist TextMorph... Hilaire

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma October 2007