Re: Patch: HistoricalRevisions, atct_history support for annotation storage (used by newer ATCT)

> If this is going to go into Zope, which I think it should, we need to
> find a more generic way to handle the issue.  The current patch is short
> and simple, but it only handles __annotation__ attributes.  It provides a
> very simple fix for the issue at hand (and actually works very well for
> our needs!), but probably isn't something the Zope folks would want to  
> add
> to Zope.

Adapters. Zope 3. Mmmm :)

I see the problem. Perhaps we can replicate some of this code at the AT  
storage level and not have to use OFS.* directly at all instead?

> The larger issue at hand is that the "oldstate" method in the zodb code  
> is
> flawed.  It works fine for very simple objects with attributes, but as
> soon as there are any subobjects, it just pulls the newest revisions of
> the subobjects.  Because subobjects are all stored and versioned
> independently in ZODB, this problem could probably be fixed by simply
> making sure we get versions of subobjects with the same serial number/tid
> that was used to pull the base object.  Ideally we want this to happen  
> for
> *all* subobjects, not just our "__annotation__" OOBtree.

I don't really follow this ... hoping someone else does.

> After following the code through its paces, I think I've found a single
> line of code in Connection.py that is ultimately responsible for this
> behavior. I think a better long-term solution could be accomplished by
> patching a couple of the methods in ZODB/Connection.py and
> ZODB/serialize.py.

Ouch - that sounds pretty nasty and invasive. Try it on the zope-dev list  
perhaps, they may like the idea. If not, can you think of any workarounds  
at the AT level?

> I still need to do some additional testing, but I think I might have
> something that will work. As soon as I test some things (and hopefully
> write some unit tests per Martin's suggestion), I'll post a patch to the
> list/tracker -- hopefully within a week or so.

That's awesome - thank you very much. We really want this feature, and I  
hope we can find a way to make it work. I'm thinking the AT storage layer  
is possibly a more appropriate location for any invasive custom code for  
now, but ideally it'd go down to Zope core. Try it.

Martin

-- 
(muted)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642