[Zope3-dev] I've updated the proposal on using parent references rather than context wrappers

[Jim Fulton]

Phillip J. Eby wrote:
> At 05:31 AM 8/13/03 -0400, Jim Fulton wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> At 05:18 PM 8/12/03 -0400, Jim Fulton wrote:
>>>
>>>> It's now in the Wiki at:
>>>>
>>>> http://dev.zope.org/Zope3/ParentGeddon.
>>>>
>>>> Comments are still welcomed.
>>>
>>>
>>> In the proposal, you say that "you can't create a mapping in which 
>>> the identity of an object is used as a key, because an object's 
>>> identity isn't constant."  Do you mean to say that a persistent 
>>> object's in-memory 'id()' is not constant?
>>
>>
>> Right, and neither is a non-persistent object's, accross runs. :)
>>
>> It is temptin to use a persistent object's _p_oid (or some variation
>> of it), but that has two disadvantages:
>>
>> - It requires persistense,
> 
> 
> Doesn't the object hub?   I mean, sure you could use paths to access some
> non-persistent object pickled inside a persistent one, currently, but 
> direct reference isn't going to work for that.  You'll just end up with 
> two copies of the non-persistent object, won't you?

Hm, that's an interesting question. I'll need to think about that.

I think it's a feature of the hub to be able to provide ids for non-persistent
objects.  For example, I'd like to be able to assign hub ids to data from
RDBMSs, but, perhaps someone should call YAGNI on that, especially given APE.

???

> 
>> - the _p_oid isn't retained accross export/import operations. Perhaos
>>   I shouldn't worry about this, but I do.  I imagine a situation where
>>   objects are archived and then restored.
>>
>> These might be overcomable.
> 
> 
> If oids were GUIDs, they could be retained across export/import without 
> fear of collision. 

Yes, an in fact, they might even be usable as GUIDs now, given that most
storages allocate them sequentially. In particular, if a storage was never
allowed to reuse an oid, then all that would be needed would be to assign the
database a GUID of some sort and then a unique identifier could be constructed
by combining the database GUID and the oid.


 > OTOH, they couldn't be used for copying, since they
> would then *update* an existing object.  (But, that's a *feature* in 
> many circumstances.)  I suppose you'd have to have 'Import (Copy)' and 
> 'Import (Update)' options.

Right, something like that.

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org