[ZODB-Dev] Packless and copyTransactionsFrom()????
JohnD.Heintz
JohnD.Heintz
Mon, 20 Aug 2001 17:04:49 -0500
On Monday 20 August 2001 16:42, Jim Fulton wrote:
>
> Another way to look at this is that using _p_oids for
> application-meaningful purposes is like using application-meaningful da=
ta
> for primary keys in relational databases.
But this is commonly done ;-) =20
>
> > > Back before I understood BTrees I assumed that the only scalable wa=
y to
> > > add millions of objects that I could then look up by ID was to use =
the
> > > database generated IDs. A little Oracle sequence dain bramage show=
ing
> > > though.
> >
> > But with a BTree you can use your own integers as indexes, so
> > there's really no point, right?
>
> You can always generate your own ids, independent of BTrees. The Zope
> catalog assigns Ids (pseudo)randomly then checks to make sure they aren=
't
> already used. The overall database consistency allows this to work in a
> multi-threaded/multi-process environment.
I think what I am looking for is database-wide lookup of objects. If _p_=
oid=20
isn't designed for application level use then we will migrate away from i=
t,=20
but I was trying to not incur the overhead (processing/conflicts/storage)=
of=20
generating my own IDs when the ZODB already provides a perfectly good uni=
que=20
ID.
Something just occured to me: In both recent and older threads implement=
ing=20
__hash__() and __cmp__() on Persistent has come up. Isn't there a seriou=
s=20
risk with Persisntent objects as keys in BTrees and export/import? Becau=
se=20
of the Buckets on import a Persistent may need to be reorganized into=20
differenct Buckets.
John
>
> Jim
>
> --
> Jim Fulton mailto:jim@zope.com Python Powered!
> Technical Director (888) 344-4332 http://www.python.org
> Zope Corporation http://www.zope.com http://www.zope.org
--=20
=2E . . . . . . . . . . . . . . . . . . . . . . .
John D. Heintz | Senior Engineer
1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com
w w w . d a t a c h a n n e l . c o m