Toby Dickenson wrote:
On 24 Oct 2000 15:14:24 GMT, [EMAIL PROTECTED] (Ty Sarna) wrote:
Unfortunately there are a lot of things that Zope just can't do because
there is no way to get a persistent "ticket" for an object that can be
handed out to some external system, and then later redeemed
Toby Dickenson wrote:
Yeah, I'd love an ID I could use to grab an object no matter how often
it was used.
I suspect you will have to build this yourself. Store a sufficiently random
id inside your objects when they are created, and use a ZCatalog to index
them.
blech! ;-)
Why
Chris Withers wrote:
I suspect you will have to build this yourself. Store a sufficiently random
id inside your objects when they are created, and use a ZCatalog to index
them.
blech! ;-)
This is the normal way to keep references to objects. I asked Jim Fulton at
IPC8, and he
Johan Carlsson wrote:
Why are the _p_oid depriciated?
Not depreciated, just "don't use them."
--
Itamar S.T. [EMAIL PROTECTED]
Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C
___
Zope-Dev maillist - [EMAIL PROTECTED]
Johan Carlsson wrote:
Why are the _p_oid depriciated?
Not depreciated, just "don't use them."
But I want too, why shouldn't I?
They solves my problems with mapping relational data to objects.
If I were to use my own random id generator I would need a global
registry for my UID. I
Johan Carlsson wrote:
Why are the _p_oid depriciated?
Not depreciated, just "don't use them."
But I want too, why shouldn't I?
They solves my problems with mapping relational data to objects.
I would guess multiple databases can have the same oid's for their objects -
and Zope does
Ty Sarna wrote:
Unfortunately there are a lot of things that Zope just can't do because
there is no way to get a persistent "ticket" for an object that can be
handed out to some external system, and then later redeemed for the
(properly wrapped) object. Pathnames are not useful, because they
On 24 Oct 2000 15:14:24 GMT, [EMAIL PROTECTED] (Ty Sarna) wrote:
Unfortunately there are a lot of things that Zope just can't do because
there is no way to get a persistent "ticket" for an object that can be
handed out to some external system, and then later redeemed for the
(properly wrapped)