Tim Peters wrote:
I know this has been raised several times in the past, but I'm not sure
of all the details...
You should believe whatever Jim tells you ;-)
Hey, what's the wink for?
What layer of ZODB, if any, has a restriction that OIDs be 8-byte
strings. Is it the persistence module? Or just FileStorage?
FileStorage uses oids that are exactly 8-byte strings. The implementation
of the FileStorage index (built on the special-purpose fsBTree type) relies
on that heavily.
The UML model for ZODB 3 claims that "In ZODB 3, object identifiers are
That's out of date.
> generally, but at least Shane Hathaway's APE got away with
using (at least for some time) much longer strings. I'm not sure where the
code actually relies on "stringness", though -- looks like most of it would
work provided oids were totally ordered, hashable, immutable, and
pickle-able (so that oids can be used as keys in Python dicts and in
I thought this was settled in:
which also mentions the requirement that oids must have len > 0. :)
We should really document this in IPersistent.
and would anyone be interested in seeing it removed.
I'm asking because I'm planning a pretty complex storage layer, which
would benefit from more complex OIDs (for instance bigger strings, or
tuples of (str, int)).
An oid is a low-level implementation thingie, and IMO that's probably not
the right place to put complexity. If you don't expect to have more than
2**N objects, an oid that requires more than N bits is in some sense
extravagant ;-). In any case, you should be able to use "bigger strings"
now without changing anything.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org