[Seaside] Persistent object framework

[C. David Shaffer]

Avi Bryant wrote:

>
> Yeah, I'd love some kind of a transparent write barrier (ie, 
> immutability bit).  We may get it with Squeak VI4, but in the meantime 
> the scanning seems the best way to go.  Unless you have any brilliant 
> suggestions?

Nope, never been accused of having one of those.   I'm going to go the 
route of scanning twice and see how bad it is for my app's performance.  
Right now GOODS is telling me that I have ~500 objects loaded in a 
typical client.  I think I can affort to scan that list twice per 
commit.  It wouldn't be too hard to switch to the manual update since I 
have tons of index-related test cases to check that I didn't miss any 
index changes.

>
> How does the explicit marking work in Gemstone?  In  OmniBase you just 
> mark a "cluster", so it works pretty well for eg Dictionary in that 
> you only have to mark the top level object and not the individual 
> associations.  Does Gemstone work roughly the same way?
>

In the specific case of indexing, Gemstone has its own indexing support 
which avoids this issue altogether.  As for the more general question 
when working with Gemstone replicants (client side versions of a server 
object) I think that the answer is no, marking an object dirty only 
indicates that the explicit object references in its ivars may have 
changed.  I've never run into a problem, though,  where I changed an 
association in a dictionary and had it been lost by GS (I simply send 
markDirty to the Dictionary).  I think that this is b/c Gemstone 
includes modifications to common collections to take care of this.  As I 
mentioned, you can configure GS to mark things dirty whenever you assign 
to an i-var or send at:put:.  Also, if you use GS forwarders (client 
keeps proxy which forwards message to GS server) then you don't need to 
do this at all since the server detects all such changes.

David