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

[Phillip J. Eby]

At 10:04 AM 8/13/03 -0400, Jim Fulton wrote:
>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.

I still think there's a place for the "hub" concept, in terms of providing 
ID's and retrieving objects by ID.  I'm just thinking the default 
implementation would require persistence and use _p_oids.  Perhaps, if an 
object is not persistent (or the hub can't retrieve the oid, in the lookup 
case), a hub service may choose to pass the object on to a parent service 
for resolution.



>>>- 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.

True, but then what happens if somebody makes a copy of the storage?  If 
each oid can stand alone as a GUID, (rather than using a database-level 
value to ensure it's unique), then copying a storage results in two 
databases that can potentially be synchronized, without any conflict being 
caused by adds occurring in either database.  If you use a database-level 
value for differentiation, then the two copied databases will immediately 
begin to conflict in ID assignments, and they are thus no longer true GUIDS.

The principal downside to this approach is that GUIDs are twice as long as 
current ZODB OIDs.  On the other hand, this size increase may be more than 
made up for in practice by not having to update BTree pages for the default 
object hub.


> > 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.

Notice that when combined with the new "location" capabilities, you can do 
an export that only includes a given subtree of the site.  Even if it 
contains direct references to objects outside the exported subtree, those 
references could be reconstituted in the receiving site, as long as the 
referenced objects had previously been imported at the destination, or the 
destination was originally a copy of the source.  Of course, on import it 
would be necessary to verify that all pointers referenced objects in the 
exported file, or objects accessible within the importing site.