Tim Peters wrote:
[Florent Guillaume]

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
8-byte strings"

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

Reply via email to