Hi Guys:
I'm newbie with Magma, but finally want to try it.
I want to test a system that is a singleton, whose root class inherits from Object.
The problem is that the system is really big, with lots of instances of business objects and, as I don't know another way, I tried (as stated on Getting Started):
MagmaRepositoryController create: 'c:\myMagmaFolder' root: Dictionary new
were instead "Dictionary new" I did "MySystem current" (the singleton instance that permit to reach all the objects of the system).
And here start the doubts:
1. Soon I get the serialization problem with the 10MB limit. How I should manage this situation to create the repository by parts, to avoid the size problem, doing commits more frequently if all I can do is point my whole system to #root: ?
2. If the system were little (not problem with the serialization limit), only doing the above sentence I get the repository and the objects persistent?
3. Is acceptable to use a class that inherits from Object instead Dictionary (as in the example) to point the root object? Considerations of each alternative?
4. Is acceptable/possible to have more than 1 repository to 1 system ?
Well, it's all for now, sorry if are so simple questions, but as I've said, I'm stating with Magma.
Cheers.
Hi Germán,
business objects and, as I don't know another way, I tried (as stated on Getting Started):
MagmaRepositoryController create: 'c:\myMagmaFolder' root: Dictionary new
The getting started only uses a Dictionary because it doesn't want to be partial to any sort of domain. It is actually something I recommend against doing nowadays.
were instead "Dictionary new" I did "MySystem current" (the singleton instance that permit to reach all the objects of the system).
Now, you do NOT want to have your root persistent object continue to be a referenced in the image by some class variable. This will cause the entire database to remain in memory and slow your commits to a crawl, among other potential identity issues if you have multiple users.
Instead, just treat the repository root as the new "location" of your singleton instance, accessed by "mySession root".
And here start the doubts:
- Soon I get the serialization problem with the 10MB limit. How I should
manage this situation to create the repository by parts, to avoid the size problem, doing commits more frequently if all I can do is point my whole system to #root: ?
If you have a large model already in the image that you need to initially persist, you can simply eliminate the 10-meg safety limit check and commit the thing in one big transaction. Be patient, it may take a while, but its a one-time thing. Once committed, you can reinstate the safety check and access the model normally.
- If the system were little (not problem with the serialization limit),
only doing the above sentence I get the repository and the objects persistent?
I may not be reading what you're asking here correctly, but I think the answer is yes. You can do "one big commit" just for the initial "load" and then after that your application program should commit single "units of work", changes to the model that must be committed as a whole (like a monetary transfer from one account to another), but only that unit of work, as is reasonably feasible.
- Is acceptable to use a class that inherits from Object instead Dictionary
(as in the example) to point the root object? Considerations of each alternative?
Yes, not only is it acceptable, it is recommended to use a meaningful domain object as your root instead of a not-so-meaningful Dictionary.
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
Well, it's all for now, sorry if are so simple questions, but as I've said, I'm stating with Magma.
Cheers, Chris
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
That sounds very good. How does the forwarding proxy know where to reach the object? Does the proxy know some repository id and that will work as long as I have a session open pointing to the corresponding repository?
thanks,
Norbert
Norbert Hartl wrote:
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
That sounds very good. How does the forwarding proxy know where to reach the object? Does the proxy know some repository id and that will work as long as I have a session open pointing to the corresponding repository?
thanks,
Norbert
The "Magma seasideHelper" framework has code for this partitioning. You define a root object for each partition or domain, and then use aMagmaSessionHelper rootAs: TheDomainRootClass to return the appropriate root object... well at least that is the theory. I havent had as much chance as I would like to test this out fully.
It may be a useful idea to pull this functionality out into a package that is not dependant upon seaside.
Keith
On Thu, 2008-04-17 at 17:54 +0100, Keith Hodges wrote:
Norbert Hartl wrote:
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
That sounds very good. How does the forwarding proxy know where to reach the object? Does the proxy know some repository id and that will work as long as I have a session open pointing to the corresponding repository?
thanks,
Norbert
The "Magma seasideHelper" framework has code for this partitioning. You define a root object for each partition or domain, and then use aMagmaSessionHelper rootAs: TheDomainRootClass to return the appropriate root object... well at least that is the theory. I havent had as much chance as I would like to test this out fully.
So, this will also work on an arbitary number of magma databases on several hosts?
Norbert
Norbert Hartl wrote:
On Thu, 2008-04-17 at 17:54 +0100, Keith Hodges wrote:
Norbert Hartl wrote:
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
That sounds very good. How does the forwarding proxy know where to reach the object? Does the proxy know some repository id and that will work as long as I have a session open pointing to the corresponding repository?
thanks,
Norbert
The "Magma seasideHelper" framework has code for this partitioning. You define a root object for each partition or domain, and then use aMagmaSessionHelper rootAs: TheDomainRootClass to return the appropriate root object... well at least that is the theory. I havent had as much chance as I would like to test this out fully.
So, this will also work on an arbitary number of magma databases on several hosts?
Norbert
Actually, I didnt read fully what Chris was proposing. I think we need some documentation on the ForwardingProxy since I myself have no idea how to acomplish what he is proposing. I think that he is suggesting that we place data from different domains in separate databases.
My scheme is for placing data from different domains into a single database. Each domain root class knows where it is stored in relation to the overall database, so that the client doesnt have to know the details. The theory being to allow modules to be published that can be combined, without any need for configuration. E.g. a users accounts, logging in and management module for seaside could be combined with a webshop module, or a blogging module.
Keith
Actually, I didnt read fully what Chris was proposing. I think we need some documentation on the ForwardingProxy since I myself have no idea how to acomplish what he is proposing. I think that he is suggesting that we place data from different domains in separate databases.
As mentioned, take a look at MagmaForwardingProxy. Here is its class comment:
"I refer to an object in the repository indicated by my 'magmaId'. You send me a message and I'll signal my session to try to connect if necessary and forward the message on to the real object in that repository.
If my session cannot make a connection, I will create an "MagmaOfflineObject" which will remember the message you sent and try to send it when the session becomes available."
There is a testcase for this you can look at for more information. See #testAutoConnectingForwardingProxy.
Now, I think this function will need some more consideration and refinement. I would like to entertain the idea of integrating Promises, for example, instead of the existing "OfflineObject". Any ideas are welcome.
- Chris
Thanks by the response Chris.
Thinking a bit about your responses, I started migrating the business objects to Magma, and I already completed some collections!.
But I must to learn a lot yet, and surely will be here asking again soon :)
Cheers and thanks by the help.
Germán.
2008/4/16, Chris Muller asqueaker@gmail.com:
Hi Germán,
business objects and, as I don't know another way, I tried (as stated on Getting Started):
MagmaRepositoryController create: 'c:\myMagmaFolder' root: Dictionary new
The getting started only uses a Dictionary because it doesn't want to be partial to any sort of domain. It is actually something I recommend against doing nowadays.
were instead "Dictionary new" I did "MySystem current" (the singleton instance that permit to reach all the objects of the system).
Now, you do NOT want to have your root persistent object continue to be a referenced in the image by some class variable. This will cause the entire database to remain in memory and slow your commits to a crawl, among other potential identity issues if you have multiple users.
Instead, just treat the repository root as the new "location" of your singleton instance, accessed by "mySession root".
And here start the doubts:
- Soon I get the serialization problem with the 10MB limit. How I
should
manage this situation to create the repository by parts, to avoid the
size
problem, doing commits more frequently if all I can do is point my whole system to #root: ?
If you have a large model already in the image that you need to initially persist, you can simply eliminate the 10-meg safety limit check and commit the thing in one big transaction. Be patient, it may take a while, but its a one-time thing. Once committed, you can reinstate the safety check and access the model normally.
- If the system were little (not problem with the serialization
limit),
only doing the above sentence I get the repository and the objects persistent?
I may not be reading what you're asking here correctly, but I think the answer is yes. You can do "one big commit" just for the initial "load" and then after that your application program should commit single "units of work", changes to the model that must be committed as a whole (like a monetary transfer from one account to another), but only that unit of work, as is reasonably feasible.
- Is acceptable to use a class that inherits from Object instead
Dictionary
(as in the example) to point the root object? Considerations of each alternative?
Yes, not only is it acceptable, it is recommended to use a meaningful domain object as your root instead of a not-so-meaningful Dictionary.
- Is acceptable/possible to have more than 1 repository to 1 system ?
Yes, not only is it acceptable, it is recommended to partition your domain by meaningful boundaries. For example, in my system I separate the Accounting domain from the Contacts; each in their own repository, even though Accounts reference Contacts residing in the other repository. This is accomplished via MagmaForwardingProxy.
This partitioning provides many benefits.
Well, it's all for now, sorry if are so simple questions, but as I've
said,
I'm stating with Magma.
Cheers,
Chris
"Chris Muller" asqueaker@gmail.com wrote in message
The getting started only uses a Dictionary because it doesn't want to be partial to any sort of domain.
Which is the most current "getting started" place for using Magma with Seaside?
Sophie
magma@lists.squeakfoundation.org
-
Chris Muller -
Germán Arduino -
itsme213 -
Keith Hodges -
Norbert Hartl