I think the exporting connection may be in a dangerous state after
calling copy_obj.  The problem is that other Persistent instances
(that don't get disconnected) may have references to some of the
disconnected instances.  If these get pickled, then you could end
up with unexpected clones of some or all of your disconnected instances.

This risk could be avoided, I think,  by forcing copy_obj to actually
close the exporting connection (or at least to ghostify every loaded
object).

On Mar 2, 2005, at 1:46 PM, A.M. Kuchling wrote:
> Iteration 2: copy_obj() takes an object and cleans off the
> ..._p_connection and ._p_oid attributes.  The resulting object, untied
> to any particular connection, can be placed in a different Durus
> database.  export_object(obj, filename, key) opens the storage
> 'filename' and records a copy of the object in the root object using
> 'key'.  import_object(filename, key) opens the storage and returns a
> cleaned copy of the object stored under 'key'.  This interface lets