Magma December 2009

magma@lists.squeakfoundation.org

5 participants
7 discussions

[ANN] r44Beta1 (was: Error while committing: applied.images max file size??)
by Chris Muller 28 Dec '09

28 Dec '09

Thanks for the report Bart. On July 8th, it appears I changed the method MaRecoveryRecord>>#writeTo: to add a call to setToEnd, and this would appear to be the cause of this file-growth problem. The reason for the change was that a warm-backup could request an earlier commit-log record in the current active commits.log file, which would cause a reposition of the file-pointer. I therefore made it the responsibility of the process doing the writing to position to its desired position just before writing, rather than assuming it would be in the correct position (eof). What I failed to remember at the time is that method is generic, being also used for the before-images file (applied.images), which expects to be writing always from the *beginning* of the file, not the end. So my fix was put in at too low a level and inadvertently introduced this new bad bug, sorry. I've moved the fix to the proper place and released it as r44Beta1 on the "MagmaTester" project of squeaksource. I'm quite certain this will fix the problem for you. Would you please let me know if you encounter any further problems? - Chris PS - Shut down the db, you can then delete your old applied.images. On Fri, Dec 25, 2009 at 8:40 AM, Bart Gauquie <bart.gauquie(a)gmail.com> wrote: > Dear all, > > I'm getting following error trying to add a new entry to a Magma Database: > aString: 'File write failed' > see attachment for more details. > The error is that the 'applied.images' file has reached 2 Gigabyte on my > machine. All the commits I've done, happened in the same session ... > Stopping and starting database does not work, because Magma again tries to > write to the applied.images file. Restarting the image does work, since the > applied.images file is empty again. > Is this a known issue ? Should Magma not 'rotate' the file if it reaches the > maximum ? I'm using Ubuntu Linux 9.10 64 bit; with ext4 as a filesystem. > Thanks for any help, > Kind Regards, > Bart > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere - > Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The important thing > is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - Albert > Einstein > Gravitation is not responsible for people falling in love. - Albert Einstein > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

2 1

Error while committing: applied.images max file size??
by Bart Gauquie 25 Dec '09

25 Dec '09

Dear all, I'm getting following error trying to add a new entry to a Magma Database: aString: 'File write failed' see attachment for more details. The error is that the 'applied.images' file has reached 2 Gigabyte on my machine. All the commits I've done, happened in the same session ... Stopping and starting database does not work, because Magma again tries to write to the applied.images file. Restarting the image does work, since the applied.images file is empty again. Is this a known issue ? Should Magma not 'rotate' the file if it reaches the maximum ? I'm using Ubuntu Linux 9.10 64 bit; with ext4 as a filesystem. Thanks for any help, Kind Regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

1 0

printString usage in Magma
by Bart Gauquie 23 Dec '09

23 Dec '09

Dear all, We're using Magma to develop an app; in the gui we're sometimes using anObject printString to show the default properties of an object. I've noticed that if Magma has a proxy in its place, it prints anObject instead of the printString I defined on that class. Looking at the definition of MAProxyObject, that seems logical that Magma does that. I will define my own own method to print these default properties of the class? I suppose printString is regarded as a 'textual description', but not to print info to the end user? I come from a Java world there you have the toString() method, is this analogous to the printString in Squeak? Thanks for any advice, Kind Regards, Bart

1 0

Large applied.image file
by snoobabk＠yahoo.ie 17 Dec '09

17 Dec '09

Hi I have a simple monitoring app that is running fine except the applied.image file has grown to about 3GB while the actual amount of data is small +- 50000 records. Any idea on how to keep the size under control? Cheers Carlo Sent from my BlackBerry® wireless device -----Original Message----- From: magma-request(a)lists.squeakfoundation.org To: <magma(a)lists.squeakfoundation.org> Subject: Magma Digest, Vol 46, Issue 7 Send Magma mailing list submissions to magma(a)lists.squeakfoundation.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.squeakfoundation.org/mailman/listinfo/magma or, via email, send a message with subject or body 'help' to magma-request(a)lists.squeakfoundation.org You can reach the person managing the list at magma-owner(a)lists.squeakfoundation.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Magma digest..." Today's Topics: 1. [ANN] MagmaBrowser (Hern?n Morales Durand) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Dec 2009 07:18:33 -0300 From: Hern?n Morales Durand <hernan.morales(a)gmail.com> Subject: [ANN] MagmaBrowser To: magma(a)lists.squeakfoundation.org, Pharo Development <pharo-project(a)lists.gforge.inria.fr>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Message-ID: <70da5dd20912160218i57e1fac5td34d4c0993c7bd0(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Dear all, I did a new Browser for the Magma object-oriented database, implemented on top of the OmniBrowser framework. I've uploaded a demo video in YouTube for the impatient : http://www.youtube.com/watch?v=VxUaOFRHFPk The project Home Page is : http://swikicaicyt.homeip.net/WebOpus/56 (you may access to other projects using http://www.caicyt.gov.ar/letodoc/paquetes-publicados) you will find there pre-built images ready for download for both Pharo and Squeak, besides installation instructions for installing and testing the MagmaBrowser in your image. Currently the status is under testing and bug-fixing, and I know there is a lot of things I should include, but you may take a look anyway as I browsed local repositories without problems last times I've used it, so I hope you may find it useful too. Finally, I want to publicly thank to Norberto Manzanos for letting me doing this, Chris Muller for his nice reviews and the OmniBrowser developers for mantaining such a great framework. HernÃ¡n ------------------------------ _______________________________________________ Magma mailing list Magma(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma End of Magma Digest, Vol 46, Issue 7 ************************************

2 1

[ANN] MagmaBrowser
by Hernán Morales Durand 16 Dec '09

16 Dec '09

Dear all, I did a new Browser for the Magma object-oriented database, implemented on top of the OmniBrowser framework. I've uploaded a demo video in YouTube for the impatient : http://www.youtube.com/watch?v=VxUaOFRHFPk The project Home Page is : http://swikicaicyt.homeip.net/WebOpus/56 (you may access to other projects using http://www.caicyt.gov.ar/letodoc/paquetes-publicados) you will find there pre-built images ready for download for both Pharo and Squeak, besides installation instructions for installing and testing the MagmaBrowser in your image. Currently the status is under testing and bug-fixing, and I know there is a lot of things I should include, but you may take a look anyway as I browsed local repositories without problems last times I've used it, so I hope you may find it useful too. Finally, I want to publicly thank to Norberto Manzanos for letting me doing this, Chris Muller for his nice reviews and the OmniBrowser developers for mantaining such a great framework. Hernán

1 0

Magma Transactions - MagmaCommitConflictError
by Bart Gauquie 10 Dec '09

10 Dec '09

Dear all, I've been trying out the MagmaCommitConflictError in Magma. I'm experiencing following which I do not understand. I've attached a changeset with a test case reproducing the behaviour I do not understand. If I follow the steps outlined at: http://wiki.squeak.org/squeak/2636* *a MagmaCommitConflictError is thrown. (see testTriggerACommitConflictSequenceAsDescribedOnWiki and a little modification on that: testTriggerACommitConflictLoadObjectBeforeStartingATransaction) If I however execute testTriggerACommitConflictUsersCommitAfterEachOtherButWithTheSameVersionOfObjectInitiallyLoaded |firstSession secondSession mockObjectRefByFirstSession mockObjectRefBySecondSession| [firstSession := (MagmaRemoteLocation host: 'localhost' port: self databasePort) newSession. firstSession connectAs: 'firstSessionUser'. firstSession commit: [ firstSession root at: 'mockObject' put: (SomeMockDomainObject new aField: 'aField content'; yourself)]. secondSession := (MagmaRemoteLocation host: 'localhost' port: self databasePort) newSession. secondSession connectAs: 'secondSessionUser'. mockObjectRefByFirstSession := firstSession root at: 'mockObject'. "User 1 is loading the object" mockObjectRefBySecondSession := secondSession root at: 'mockObject'. "User 2 is loading the same version of the object as User 1" firstSession begin. "1. User 1 begins a transaction." mockObjectRefByFirstSession aField: 'aField updated by user 1'. "3. User 1 changes Object A." firstSession commit. "4. User 1 commits his transaction." secondSession begin. "2. User 2 begins a transaction." mockObjectRefBySecondSession aField: 'aField updated by user 2'. "5. User 2 changes Object A." self should: [secondSession commit. "6.7. User 2 commits his transaction"] raise: MagmaCommitConflictError. firstSession refresh. self assert: 'aField updated by user 1' equals: ((firstSession root at: 'mockObject') aField). self assert: 'aField updated by user 1' equals: ((secondSession root at: 'mockObject') aField). self assert: 'aField updated by user 1' equals: (mockObjectRefBySecondSession aField). ] ensure: [[firstSession commit: [ firstSession root removeAll]. firstSession disconnect] ensure: [secondSession disconnect]] It failes and I dont understand why. The test is what you get in a typical web application. User 1 has a session on the database. User 2 has another session. Both opened an item. Both are editing it and then first user1 commits his changes. User 2 wants to commit his changes but did not see the updated data of User 1. The test failes at : self should: [secondSession commit. "6.7. User 2 commits his transaction"] raise: MagmaCommitConflictError. => MagmaCommitConflictError is not thrown. Which is something I do not understand. User 2 is trying to commit a change on an object some other session already changed. So User 2 is trying to update a stale version. Is there a reason why no MagmaCommitConflictError is thrown? Furthermore, if you proceed on the failing MagmaCommitConflictError; refresh the firstSession; i notice that the changes made by Session2 effectively got committed; which surprises me even more. Because that means that the changes made by User 1 got overridden by the changes of User 2 without User 2 even knowing. If I read the information on the wiki, this behaviour is correct since Magma will only detect if during a transaction (after begin has been called) some other session has committed changes on the object being changed. Off course this is not the kind of behaviour you have if you're developing web applications since there, the transactions are very short. Is there a way to detect if an object was updated by another transaction, but not within my own transaction; so that stale updates do not happen. I suppose there is some version on a persisted object you can check and if the last committed version of an object is higher than the version in the current session, this also means a magmacommitconflicterror? But I havent found any info about that yet? Thanks for any help. Kind Regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

3 5

MagmaCollectionReader sortBy: total number of elements in list?
by Bart Gauquie 10 Dec '09

10 Dec '09

Dear all, I've been using the MagmaCollectionReader to develop a paged view over some collection. I'm using this paged view in a seaside app. This shows if there is a previous or a next page and the number of items being shown now: 1 - 21 of 2867. If I do a query on a MagmaCollection using a sortBy: clause; some things go sometimes a bit wrong. If I do a query using a sortBy: ; then i can check if sortComplete. Using a query without sortBy:, I can know the total number of items by calling lastKnownSize. If I do a sortBy: query, the lastKnownSize returns the max number already sorted (which is not ok in my gui; I need the total of that query). However I noticed that u can also use fractionSorted to know how much items already have been sorted, and derived from that how much items there are in total. For instance: Last known size: 2249 Fraction Sorted:(2249/6065) So I wrote code like this to already know and show the total numbers of the search, even if the search is still going on on the server, like this I can then already show the first page with the result, while the server is still creating further pages totalNumberOfElements ^(magmaCollectionReader sortComplete) ifTrue: [magmaCollectionReader lastKnownSize] ifFalse: [|fractionSorted| fractionSorted := magmaCollectionReader fractionSorted. (fractionSorted = 0) ifTrue: [self totalNumberOfElements]. (fractionSorted isFraction) ifTrue: [fractionSorted denominator] ifFalse: [magmaCollectionReader lastKnownSize]]]. This works mostly. If the fraction gets reduced however, the denominator returns a too low number off course. Is there any other way to know the total number of items in the search, even if it is still going on the server? If I follow the code into MaQueryExecutor>>fractionComplete ^ trunkPosition ifNil: [ 0 ] ifNotNil: [ | trunkSize | trunkSize _ self trunk trunkSize. trunkSize = 0 ifTrue: [ 1 ] ifFalse: [ trunkPosition / self trunk trunkSize ] ] I understand where the 0 can come from & where the reduction comes from. Integer/anotherInteger automatically does a reduce. If I on the server Image change MaQueryExecutor>>fractionComplete ^ trunkPosition ifNil: [ 0 ] ifNotNil: [ | trunkSize | trunkSize _ self trunk trunkSize. trunkSize = 0 ifTrue: [ 1 ] ifFalse: [* Fraction numerator: trunkPosition denominator: self trunk trunkSize* ] ] It works because the reduce is then not done. This is a bit of hack off course. Is there any other way of doing this? Thanks for any help. Kind Regards Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma December 2009