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

[Steve Spicklemire]

Hi Steve,

Ahh.. a performance issue. ;-) That makes sense! These practical things
always complicate otherwise simple ideas. Sometimes I think it makes
sense to produce a "concept" implementation first, then keep that around
in a doc string as an "interface preserving implementation serving as
documentation" for the poor slobs who come in to the source code and
don't know all the slick tricks used to improve performance. Anyway..
thanks again for the explaination.

Looking at all this code makes me wonder again about something that's
been nagging at me for some time. It's related to transactions, so I
thought maybe I'd run it by you (and everyone else in the group, whether
they like it or not!) and see what you/they think. 

So here it goes: I have a product that I cooked up for version control
(ZCVSFolder). It's kind of a kludge, but it has tremendous practical
value, for me at least. I'd like to clean up some of the kludgisms and
this is one of them. ZCVSFolder uses the built in import/export
mechanism to import and export zope objects to the filesystem where CVS
can manage them. It then uses import/export to update zope. This works
pretty well for SimpleItemish things, but not so well for Folderish
things. 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

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

and/or

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

Does anyone have any reaction to those thoughts?

thanks!
-steve

Steve Alexander wrote:
> 
> Steve Spicklemire wrote:
> 
> > Yes.. in Python I'm used to something like:
> >
> > class Foo
> >
> >       myFoo = None
> >
> >       def getMyFoo(self):
> >               if self.myFoo is None:
> >                       self.myFoo = MyFoo()
> >
> >               return self.myFoo
> >
> > Which seems pretty clear to me!
> >
> > What's the main advantage of the ComputedAttribute version? Is it just
> > sytactical (i.e., it doesn't look like a method call, but rather an
> > instance varible)?
> 
> With the implementation pattern you see in ZPatterns, once you've set up
> the attribute, there is no overhead on each retrieval.
> 
> --
> Steve Alexander
> Software Engineer
> Cat-Box limited