Hi,
I've been trying to test Magma and coming up with some problems.
First, let me give you some background information:
Class FHKC834Parser is simply a class that, given an EDI compliant data file, will parse the file and create an object of class FHKC834Header, which contains amongst its 5 attributes, an attribute named 'members'. The purpose of attribute members is to store a LinkedList of FHKC834Entry objects, which represent the individual records from the EDI data file. Class FHKC834Entry basically has 27 String attributes that make up an EDI record.
Because I am not interested in referencing these EDI file transfers directly, I decided to store the FHKC834Header objects in a LinkedList in the database. The only purpose of these objects is strictly for iteration through its members. Therefore, in the application, the only functionality that will be built to manage these objects is to sequentially iterate through the LinkedList of FHKC834Header objects and once the user selects a "header" object, the system will sequentially iterate through its members attribute.
Having done this, I tried loading a sample data file. This file contains 8784 records out of approximately 130,000 text lines.
The first thing to point out is that while FHKC834Parser#parseFile is executing, the VM is locked in that process and everything else is unresponsive. This does not worries me so much because: 1) this process only happens once a week, 2) I think that by forking this job within a low priority process it will be solved, independently of how long it takes to parse the text file. Regardless, on a PowerBook G4 1.5Ghz, it takes 24 seconds to process this file.
All this is being done with Squeak V3.7-5989-Full. Also, I downloaded the latest Monticello packages of Magma from http://kilana.unibe.ch:8888/MagmaTester/
Now, onto the Magma problem(s):
I launched a Squeak VM with its own, brand new, full image. The only additional packages loaded in the image are the Magma-server related packages. On this separate VM, I execute the following in a Workspace window:
"First create the repository" MagmaRepositoryController create: 'Macintosh HD:Users:myUser:myRepository.magma' root: Dictionary new
"Then launch the server" ms := MagmaServerConsole new open: 'Macintosh HD:Users:myUser:myRepository.magma' processOn: 51969
After I executed this, I inspected ms to see that it is of MagmaServerConsole type and has an attribute called statistics, which I'll come back to later. So far, everything seemed to be working.
Then, I launched another Squeak VM with its own full image. This image had loaded some additional packages, including, Magma client and Seaside.
In a workspace, I executed the following:
"Load EDI file and show some information in the Transcript window" Transcript clear.
t := Time millisecondsToRun: [p _ FHKC834Parser new. xmt := p parseFile: 'RDTLMCNA0405.EDI'].
Transcript cr; show: (t/1000) asFloat; show: ' seconds to load datafile'. Transcript cr; show: (xmt members size); show: ' member records loaded.'.
The above, simply loaded the EDI file and stored the results in a variable named xmt. xmt is now an object of FHKC834Header with an attribute named members of type LinkedList with 8784 FHKC834Entry objects.
This ran with no problem other than using 100% of the VM CPU time.
Then, I tried connecting to the Magma server and adding this xmt object into it in a single commit, as follows:
t := Time millisecondsToRun: [mySession := MagmaSession hostAddress: #(127 0 0 1) asByteArray port: 51969. mySession connectAs: 'auser'. mySession commit: [mySession root at: 'FHKC834' put: (LinkedList new)].
mySession commit: [fhkc := mySession root at: 'FHKC834'. fhkc add: xmt].
mySession disconnect].
Transcript cr; show: (t/1000) asFloat; show: 'Seconds to load into DB in one commit'.
This successfully seemed to have connected to the Magma server, created a root object and added the xmt object under the 'FHKC834' root dictionary element.
When I ran this, it still takes all of the VM CPU time and after 19 minutes, it came back with an exception:
MaObjectSerializationSecurityViolation signal: Serializations beyond 10 megabytes are not allowed.
Well, that sucked. Then, I decided to break the commits into individual object commits. For that, I executed the following:
head := FHKC834Header new. head controlNumber: (xmt controlNumber). head referenceNumber: (xmt referenceNumber). head date: (xmt date). head time: (xmt time). head members: (LinkedList new).
t := Time millisecondsToRun: [mySession := MagmaSession hostAddress: #(127 0 0 1) asByteArray port: 51969. mySession connectAs: 'auser'. mySession commit: [mySession root at: 'FHKC834' put: (LinkedList new)].
mySession commit: [fhkc := mySession root at: 'FHKC834'. fhkc add: head].
xmt members do: [:ea| mySession commit: [head addMember: ea]].
mySession disconnect].
Transcript cr; show: (t/1000) asFloat; show: 'Seconds to load into DB in multiple commits'.
Basically, I created en empty FHKC834Header object (empty in the sense that the members attribute is an empty LinkedList), and commit that. Then I add each new FHKC834Entry into head's members attribute, each within a commit.
This, again, successfully seemed to have connected to the Magma server, created a root object and added the xmt object under the 'FHKC834' root dictionary element.
When I ran this, it still takes all of the VM CPU time and after 11 minutes, it came back with an exception:
MagmaSoftwareError signal: #UndefinedObject, should implement maIsChangedFrom:using:. MaByteObjectBuffer(MaVariableBuffer)>>isDifferente:using: [] in MaTransaction>>changedObjects {[:eachCurrent :eachBuffer | (eachBuffer isDifferent: eachCurrent using: session serializer) ...
Well, that sucked again.
What am I doing wrong? Is it me or is it Squeak or is it Magma? Please keep in mind, this is my first Squeak and Smalltalk project ever. Also, it's the first time I use Magma, and an OODB ever (I come from a relational world). Does anyone have any suggestions? I can post the code of the FHKC834* classes as well as a sample data file, if anyone is interested in trying it and make recommendations, but I don't think the problem is there, since it's simply storing a collection of objects. By the way, FHKC834Header and FHKC834Entry both inherit from Link.
Thanks again, Daniel
squeak-dev@lists.squeakfoundation.org