Here is a situation I am wondering how Magma will deal it -- or any OODB.
Let's say we have MyApplication where is defined a class User with an attribute 'company' referencing an instance of the Company class.
Now MyApplication is runned in a Squeak instance A and in a Squeak instance B. So we have myApplicationA and myApplicationB running in two different Squeak images.
In myApplicationA, userA instance is defined. In myApplicationB, userB instance is defined.
userA and userB's company attribute is set to be semantically identical, ie userA company = userB company. Of course it is not the same instances as there are physically located in different images.
Now userA is persisted in a MagmaDB, and userB in the same MagmaDB. Now I am wondering will company attribute of userA and userB be the same (same memory location) or be duplicated?
Hilaire
Hello,
I was asking similar questions a while back. These links may help:
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/276/match=qu... http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/280/match=qu...
In your companies example I think it depends upon how UserA and UserB find their companies.
Let us say, UserA's company instance is assigned by looking in the database for the company, say in a collection of possible companies. Alternatively UserA's company instance is set by referencing an instance of company that is already persisted in the database somewhere.
When UserB selects their company by the same means, then it will be the same instance in the persisted model.
I suspect that if you instanciate two different company instances in User's A&B without any previous reference to the model that when each is persisted they will be persisted as two separate entities despite the fact that all of their attributes may be the same.
There may be a way of indicating identity in such a way as to inform the database that these objects are the same. In the same way as you can define = and hash on an object so that Set sees two objects as Identical. I havnet come across this yet.
If you arrange for your companies to be persisted in some form of keyes/indexed collection and found from there, then the users are likely to find the same company instance.
hope this helps
Keith
___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html
Keith Hodges a écrit :
Hello,
I was asking similar questions a while back. These links may help:
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/276/match=qu...
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/280/match=qu...
Thanks for the indication.
In your companies example I think it depends upon how UserA and UserB find their companies.
Yes, User's company attribute refer to object defined in the local application. In fact Company instance does not need to be persisted as it is unchangeable value.
What I am afraid of is that when persisting one object I may also persist much more than I want.
Eventually User's instance should reference company through their hash value but this will add complexity. I am not sure how I should handle that situation.
If you arrange for your companies to be persisted in some form of keyes/indexed collection and found from there, then the users are likely to find the same company instance.
hope this helps
yes, thanks,
Hilaire
Yes, User's company attribute refer to object defined in the local application. In fact Company instance does not need to be persisted as it is unchangeable value.
What I am afraid of is that when persisting one object I may also persist much more than I want.
Eventually User's instance should reference company through their hash value but this will add complexity. I am not sure how I should handle that situation.
If your UserA references the company via a key/reference, then persisting the User will persist the Key, rather than the entire company datastructure.
There is are two mechanisms in magma which may help.
1. pre/post serialization, whereby you can indicate to magma that objects of a particular class are informed before they are serialised, or particular operations may be defined to be run before certain types of object are serialised. look for implementors/senders of
#beforeSerializingAny: className do: oneArgValuator and #maPreSerialize (note Chris has indicated that he wants to deprecate the use of this selector in favour of the above.
2. #maAsStorageObject
whereby an object can provide an alternative form for persisting such as a proxy reference that can be reconnected on realisation.
Keith
___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
I havent quite worked out whether there is a really simple way to use a MagmaCollection like a dictionary.
If I want to simply do what would be aDictionary at: key
Do I have to do a #where: returning a reader and then go through the results to find my exact match?
e.g.
pathLookup: aString startingAt: aStructure fallback: aBlock
^( self paths where: [ :path | path fullPath = aString ] ) detect: [ :path | path fullPath = aString ].
Keith
___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
magma@lists.squeakfoundation.org