Oops, forgot to reply-all to get it to the list. Here it is.
On Tue, Apr 26, 2011 at 8:39 PM, Chris Muller ma.chris.m@gmail.com wrote:
You're using 'self keyHash: key' to find a specific bucket that should contain that object. But 'self keyHash: key' may (and probably will) answer a different number for the same object each time it is materialized from the database unless it is somehow using the MagmaOID in place of the identityHash.
Right, you definitely cannot use Squeak's #identityHash in the equation.
Hm, let me about this a few days, I think an easy solution will appear..
maybe:
use magmaOid as keyHash.
when finding a key (#at), check if key has magmaOid first, if not, 'self errorKeyNotFound: key' because it doesn't exist in IdentityDictionary anyway.
when storing a value (#at: put:); before finding its bucket, check if key has magmaOid, if not, store key in database so it will have a magmaOid. I'm not sure what the code looks like on this last one, but it sounds good :)
when finding a key (#at), check if key has magmaOid first, if not, 'self errorKeyNotFound: key' because it doesn't exist in IdentityDictionary anyway.
..that won't work for objects that have been added to the dictionary, but not yet committed.
when storing a value (#at: put:); before finding its bucket, check if key has magmaOid, if not, store key in database so it will have a magmaOid. I'm not sure what the code looks like on this last one, but it sounds good :)
This won't work because, maybe you are already in a transaction when you decide to send #at:put:, but not yet ready to commit. I'm not sure if you meant to use #commit to "store key in database".
But you are evaluating exactly the right kinds of ideas, way to go.
With Magma's networking layer ("Ma client server", which is used independently in other apps, without Magma, BTW), it is very easy to define new types of requests and responses; they're all first-class objects. So I'm thinking of a new request-type that would be an oid-reservation for any uncommitted object so that, if that object is ever committed, that's the oid it will get.
The only downside to this is that the whole purpose of MagmaPreallocatedDictionary is to be very fast, so we don't want to require an extra trip to the server for each and every at:put:. So requests for oid reservations should bring back 100 at a time, and sessions can then dole them out one by one as they're requested. We have plenty of oid space, there is no concern about wasting a few oids if not all of them get used.
- Chris
On Wed, Apr 27, 2011 at 5:02 PM, Chris Muller asqueaker@gmail.com wrote:
With Magma's networking layer ("Ma client server", which is used independently in other apps, without Magma, BTW), it is very easy to define new types of requests and responses; they're all first-class objects. So I'm thinking of a new request-type that would be an oid-reservation for any uncommitted object so that, if that object is ever committed, that's the oid it will get.
The only downside to this is that the whole purpose of MagmaPreallocatedDictionary is to be very fast, so we don't want to require an extra trip to the server for each and every at:put:. So requests for oid reservations should bring back 100 at a time, and sessions can then dole them out one by one as they're requested. We have plenty of oid space, there is no concern about wasting a few oids if not all of them get used.
If I were to see a visual diagram of how all the parts of Magma fit together, I could come up to speed faster. Coding this is a little beyond me at the moment.
Elliot
magma@lists.squeakfoundation.org