I think this problem is actually easier to solve in the common case than
requring that people run a conversion script.  The ZGlobals data
structure is a cache, and can be blown away and recreated
indiscriminately.  It's recreated whenever a Product is added or
removed, and Zope already does this as a matter of course if anything
about the data structure is goofy.

I think the problem Sidnei has run into isn't so much that the BTree
module can't be imported, it's instead that the
Persistence.PersistentMapping module redefines PersistentMapping in
order to do something I don't quite understand, and the redefinition is
what appears to be causing the AttributeError, 'data' to appear.  If
it's not used, everything works fine.  Here's the module:

 import Persistence
 import persistent
 from persistent.mapping import PersistentMapping

 if Persistence.Persistent is not persistent.Persistent:
     class PersistentMapping(Persistence.Persistent, PersistentMapping):
         """Legacy persistent mapping class
         This class mixes in ExtensionClass Base if it is present.
         Unless you actually want ExtensionClass semantics, use
         persistent.mapping.PersistentMapping instead.

If you comment out the "if" clause and everything underneath of it, make
a dummy BTree.py module with the following and put in in the software

 from Globals import Persistent

 class BTree(Persistent):

... and restart Zope with an "old" filestorage file, all is well:

[EMAIL PROTECTED] zopemafia.org]$ bin/zopectl-trunk debug
Starting debugger (the name "app" is bound to the top-level Zope object)
>>> app.objectIds()
['acl_users', 'Control_Panel', 'temp_folder', 'browser_id_manager',
'session_data_manager', 'error_log', 'standard_error_message',
'standard_html_footer', 'standard_html_header', 'standard_template.pt',
'vhm', 'tacoma.bridge.jpg', 'tacoma.bridge1.jpg', 'index_html_orig',
'index_html', 'misc', 'innomatch', 'newplone', 'New Folder', 'scratch']
>>> root = app._p_jar.root()
>>> root
{'Application': <OFS.Application.Application object at 0x41419cac>,
<BTrees._OOBTree.OOBTree object at 0x4185826c>}
>>> type(root)
<class 'persistent.mapping.PersistentMapping'>

I'm not sure what the redefinition is supposed to achieve?

FWIW, I've sort of got plope.com (which implies Plone) working against
the trunk, although some other unrelated problems still appear to exist.

On Fri, 2003-12-12 at 10:41, Sidnei da Silva wrote:
> | I think that is true.  On the other hand, it was a bit of a surprise to
> | find a BTree in ZGlobals.  Maybe they're hiding somewhere else, too.
> At least, the script didn't found another one. It did found 7800
> objects total, of which one was a BTree (ZGlobals).
> Now, in 2.7 I get this output (starting zope via 'zopectl debug'):
> >>> app
> <Application instance at 414c8c80>
> >>> app._p_jar
> <Connection at 414ac74c>
> >>> app._p_jar.root()
> {'Application': <Application instance at 414c8c80>, 'ZGlobals':
> <OOBTree object at 0x414d1c60>, 'RefreshData': {'auto': {'CCHS': 1},
> 'products': {'Archetypes': {'dependent_products': ('CCHS',)}}}}
> Which looks sane to me. But if I copy the same Data.fs to another
> instance with Zope HEAD, the "AttributeError: data" is there again. It
> *seems* to me that the root PersistentMapping is not being unpickled
> correctly.
> > /var/src/zope/head/lib/python/ZODB/ZApplication.py(32)__init__()
> -> conn=db.open()
> (Pdb) n
> > /var/src/zope/head/lib/python/ZODB/ZApplication.py(33)__init__()
> -> root=conn.root()
> (Pdb) n   
> > /var/src/zope/head/lib/python/ZODB/ZApplication.py(34)__init__()
> -> if not root.has_key(name):
> (Pdb) print root
> *** AttributeError: data
> (Pdb) type(root)
> <class 'Persistence.PersistentMapping.PersistentMapping'>
> (Pdb) print conn.root()
> *** AttributeError: data

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to