[ZPatterns] AttributeError _v_cache ..... and another issue that's completely different

[Steve Alexander]

Steve Spicklemire wrote:

>
> I'd like to treat folderish things something like this:
> 
> def exportFolderishThing( self, aFolderishThing ):
> 	contents = aFolderishThing._objects
> 	del aFolderisThing._objects
> 	self.exportSimpleThing( aFolderishThing );
> 
> 	self.checkAndCreateIfNeeded(aFolderishThing.getId())
> 	self.setWorkingDirectoryForObject(aFolderishThing)
> 
> 	for item in contents:
> 		self.exportThing(item)
> 
> 	aFolderishThing._objects = contents


So, in a nutshell, considering an export rooted at an ObjectManager, you 
want to be able to separate out the contents (ie subobjects) of an 
ObjectManager from everything else.


> This way there is a filesystem representation of the folder, and a
> separate directory for it's contents. However I'm 97% sure this wouldn't
> work, due to all the assingments and their affect on ZODB (triggering
> new versions of objects stored in ZODB). I was thinking that I might get
> around this a couple of ways:
> 
> 1) Use aFolderishThing.__dict__['_objects'] rather than
> aFolderishThing._objects everywhere to circumvent the persistence machinery


In an ObjectManager, _objects is for cached meta-data. There is no harm 
is storing that, although I think it is redundant.

You'll need to iterate over the ids in _objects, and del those attrs 
from aFolderishThing. That's assuming it isn't something like BTree 
Folder, where rather than being stored in attrs, the subobjects are 
stored in a BTree.

You might want to get more into the persistence machinery at this point, 
and work out exactly what persistent pickles aFolderishThing consists 
of, then persist these to CVS separately. I'd start by examining its _p_jar.

Perhaps move this thread over to zodb-dev? They know all about _p_jars 
there :-)


> 2) abort() the transaction after I'm finished saving objects to prevent
> "unreal" changes from being commited to ZODB. (this sounds pretty shaky
> to me, since there might be some changes that I *do* want commited, and
> I'm not sure what else might happen if I try to abuse abort() in this
> way. A kludge to replace a kludge may be moving in the wrong direction.)


You could try using a subtransaction, then aborting that subtransaction.
It might work, but it is too early in the morning here for me to be able 
to think that through!


--
Steve Alexander
Software Engineer
Cat-Box limited