Tim Peters wrote:
[Shane]
It can do this because it has to provide its own DB and Connection
objects anyway.
[Tim]
I trust that's for more reasons than _just_ because it doesn't want to
use '\0'*8 as the root-object oid.
[Shane]
It's for uniformity. In Ape, the strategy for choosing
[Shane]
>>> It can do this because it has to provide its own DB and Connection
>>> objects anyway.
[Tim]
>> I trust that's for more reasons than _just_ because it doesn't want to
>> use '\0'*8 as the root-object oid.
[Shane]
> It's for uniformity. In Ape, the strategy for choosing OIDs is
> plug
Tim Peters wrote:
[Shane Hathaway]
It can do this because it has to provide its own DB and Connection
objects anyway.
I trust that's for more reasons than _just_ because it doesn't want to use
'\0'*8 as the root-object oid.
It's for uniformity. In Ape, the strategy for choosing OIDs is
pl
[Shane Hathaway]
> FWIW: Ape still uses variable length strings.
That's OK!
> The OIDs shrank in size because they used to contain the object's
> "physical path", but that turned out to play bad tricks with copy/paste,
A cautionary tale about getting "too fancy" with oids ;-)
> so now OIDs are
Tim Peters wrote at 2005-12-9 10:46 -0500:
> ...
>I'm not sure where the
>code actually relies on "stringness"
The "cPickleCache" explicitely checks for "stringness".
Not, that this were necessary. It just does.
--
Dieter
___
For more information abou
Tim Peters wrote:
Some "auxiliary" code would definitely break if they weren't strings. For
example, ZEO cache tracing has its own trace-file format, which originally
blew up left and right when Shane tried to use it with APE. That got
generalized (and, alas, the trace files got bigger) to live
[Florent Guillaume]
> Oh I agree, but if my storage (think SQL) has internally other kinds of
> identifiers, like autoincremented integer primary keys, and several
> tables depending on object kind, I want to reuse its concepts and pack
> them into an oid like 'footable_12345'.
I probably would no
On 9 Dec 2005, at 16:46, Tim Peters wrote:
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 pla
...
[Tim]
>> You should believe whatever Jim tells you ;-)
[Jim]
> Hey, what's the wink for?
I was just flirting with Florent ;-)
> ...
> I thought this was settled in:
>
>http://mail.zope.org/pipermail/zodb-dev/2005-March/008593.html
>
> which also mentions the requirement that oids must h
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 t
[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 ;-)
> What layer of ZODB, if any, has a restriction that OIDs be 8-byte
> strings. Is it the persistence module? Or just FileStorage?
Fi
Florent Guillaume wrote:
I know this has been raised several times in the past, but I'm not sure
of all the details...
What layer of ZODB, if any, has a restriction that OIDs be 8-byte
strings. Is it the persistence module? Or just FileStorage?
Also is there a reason (performance, space?) fo
12 matches
Mail list logo
