Alan McKean wrote:
After talking with Charlie about an approach, we decided that this is
what we would try first. It would require an additional 4-byte field in
every object. Not the optimal approach, but good enough for a
proof-of-concept.
1) Mark 'metaclass' and 'finalizer' transient. This should allow us to
persist an object without dragging the runtime classes along.
2) Add a String 'metaClassName' field to RubyObject. Initialize it in
setMetaClass() when it is first called.
3) Modify getMetaClass() to lazily initialize the metaclass variables
when the, using 'metaClassname' when the getter is first called.
Here's an alternative approach that I would like some feedback on. It's
more complicated but would not require any additional instance fields.
It would add a field to the metaclass instead.
1) Mark every field in the RubyClass transient except for one: a new
'metaClassName' field. Initialize it when the metaclass is created. When
saving an instance, save the metaclass in the database, too.
2) When the object is reloaded from the database, fault the persisted
metaclass into memory on the first instance method invocation.
3) Use lazy initializers on the metaclass fields reconnect to the
original metaclass's field references. This would mean that there would
be two identical classes: the new one hooked up to the persisted objects
(it would be the start of method lookup for persisted objects that had
been reloaded) and the original class that would continue to be used to
create new instances. Not-yet-persisted objects would use the original.
Ideas? Comments?
Only concern about the second idea is metaclass object identity. If we
have two physical objects that represent the same class, but aren't the
same object in Java, there could be problems somewhere. I just don't
know where, but it makes my spider-sense tingle.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
