Pascal Peregrina wrote:
I would like to know if in a FileStorage, the serial of some object was
equal to the transaction id where this object was modified.
Yes.
For reference, here are some emails about the tid vs. serial questions I had
a few months back and were sent to me in private but really have their place
in this list:
----
From: [EMAIL PROTECTED]
Subject: Does ZODB ever assume that tid==serial?
Date: 5 January 2006 20:16:52 GMT+01:00
<efge> J1m: quick ZODB question: I don't have a clear understanding of the
difference between a tid and an object's serial, are they the same?
<J1m> No
<J1m> They can be different.
<J1m> They are usually the same, but they aren't guarenteed to be the same.
<efge> J1m: would there be a problem if a storaged defined serials
independently of tids? Are they ever compared or one used for the other?
Not theoretically. :)
I'm 92% sure that ZODB doesn't make any assumption about this.
Tim,
Do you have an opinion?
Jim
----
From: [EMAIL PROTECTED]
Subject: RE: Does ZODB ever assume that tid==serial?
Date: 5 January 2006 21:42:46 GMT+01:00
[Jim Fulton]
> <efge> J1m: quick ZODB question: I don't have a clear understanding of
> the difference between a tid and an object's serial, are they the same?
> <J1m> No
> <J1m> They can be different.
> <J1m> They are usually the same, but they aren't guarenteed to be the
> same.
> <efge> J1m: would there be a problem if a storaged defined serials
> independently of tids? Are they ever compared or one used for the other?
>
> Not theoretically. :)
>
> I'm 92% sure that ZODB doesn't make any assumption about this.
>
> Tim,
>
> Do you have an opinion?
Several, actually, and I'm copying Jeremy so that you get even more ;-). I
believe the original intent was that they be independent, but this comment
in ZODB 3.2.10 FileStorage.py's _commitVersion() strongly suggested the code
was almost never run when tid != serial:
# XXX This might be the only time that the serialno
# of a data record does not match the transaction id.
I have a vague memory of you (Jim) and Jeremy agreeing to erase the
distinction later (since it was never-- or almost never --used), but I can't
find a discussion of this in the zodb-dev archives. This checkin comment
from Jeremy in rev 1.1.2.19 (under CVS, on an MVCC branch) reinforces that
belief, though:
Tue Dec 2 07:10:31 2003
"""
First cut at removal of serial numbers.
Rename loadNonCurrent() to loadBefore() (Jim's suggestion).
A few tests fail, but it's close enough to share the code with Tim.
In all case, the _p_serial attribute of a Persistent object matches
the id of the transaction that wrote the current revision. Within the
storage API, we eliminate the abortVersion case where the txn id is
greater than the serial number.
Rename as many variables and attributes from serial to tid, with the
exception of store() and restore() arguments. They're being passed in
from a client, which is getting the value from _p_serial; it makes
some sense there.
When tid and serial were both returned, eliminate serial and just use
tid.
Replace "serial" with "tid" in some methods names, but not all. I'll
get to the rest tomorrow. The remaining ones are just used a lot.
Add XXX comment about now-bogus ZEO protocol that passes identical
serialnos for every object committed.
"""
Staring at the files changed by that checkin suggests that the motivation
may have been to reduce the complexity MVCC was adding to the ZEO cache and
ZEO protocol. For example, the ZEO cache now maintains a (start_tid,
end_tid) validity range for non-current data, but before that checkin threw
a serialno into that mix too. Identifying "the serial" with "the tid"
certainly simplified the cache code at the time; I don't know whether it
also allowed solving an otherwise-intractable problem.
----
From: [EMAIL PROTECTED]
Subject: Re: Does ZODB ever assume that tid==serial?
Date: 5 January 2006 22:58:39 GMT+01:00
Quick answer before I start my commute home: We did decide to merge
tid and serial number completely. I think commit version was the one
remaining edge case, because the commit transaction had a tid
different than the serial numbers of the object revisions. The ZEO
cache code for MVCC was too hard to think about in the presence of
versions, so the commit version serialno change really simplified.
In summary, tids are serial numbers. I'd be willing to bet that some
code depends on it.
Jeremy
----
From: [EMAIL PROTECTED]
Subject: RE: Does ZODB ever assume that tid==serial?
Date: 6 January 2006 03:27:02 GMT+01:00
[Jeremy]
> Quick answer before I start my commute home: We did decide to merge tid
> and serial number completely.
Do you recall who "we" comprised, or whether discussion was recorded? I
struck out looking at zodb-dev archives, Wikis, and saved email. I remember
_when_ it was decided (that's how I was able to find the checkin comment
included last time), but don't have any recollection of discussing it.
> I think commit version was the one remaining edge case, because the
> commit transaction had a tid different than the serial numbers of the
> object revisions. The ZEO cache code for MVCC was too hard to think
> about in the presence of versions, so the commit version serialno
> change really simplified.
>
> In summary, tids are serial numbers. I'd be willing to bet that some
> code depends on it.
I'm sure it does now -- in part because the checkin comment mentioned
changing some methods that used to return both serial and tid to return only
the latter. It's certainly the case that the current ZEO cache only knows
about tids (and oids, versions and pickles -- no distinct concept of serial
number there anymore).
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
