June 2001 - Zope-Dev

Bug in Zope VersionControl
by Christian Theune 07 Jun '01

07 Jun '01

hello again ... Okay ... I admit using opera and enjoying it. Problem is, that opera is sooo standardsconform. See Zope/lib/python/Products/OFSP/Version.py:175 in function enter() Somebody thats the path for the cookie as SCRIPT_NAME. This seems that the scope of the versions should be limited to the subtree where the version object was instanciated. Nice idea. But this doesn't work. First: Internet Explorer and Netscape ignore the path of the cookie and assume '/'. Second: Opera is conform to the rfc of http 1.1, and this means, that the cookie is only valid for the version itself, and is not used in any place out of http://myzope:8080/blaah/myVersion Proposed solution: Change the path to '/'. And have the same behaviour on all browsers. Or: Change the path to REQUEST["URL1"] (is this the parent folder?) and have the intended mechanism working at least on opera. The last is my personal favorite, because you can have different versions concurrently open on different projects @ one server. Proposed patch for both solutions comes as attachement. (both intended for zope 2.4.0a1) (btw: remember same behaviour on function leave() ...) -- Christian Theune - ct(a)gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

5 6

Re: [Zope-dev] Bulletproof ZCatalog proposal
by Shane Hathaway 07 Jun '01

07 Jun '01

On Thu, 7 Jun 2001, Phillip J. Eby wrote: > >I was thinking that certain types of objects would be committed by the > >transaction manager before all others. In this case, the catalog (or a > >special object in the catalog) would be committed first. It would > >resolve all conflicts in the contained indices before they occur by > >replaying the changes in the persisted queues from the transaction > >history, then setting the _p_serial attributes to convince the storage > >that the conflicts have already been resolved. > > Hm. Sounds to me like what you actually want is for the transaction > manager to do this *after* everything else, rather than before. Thus, you > would catch any changes which occur *during* transaction commit - such as > commit-phase cataloging (as some folks do with ZPatterns currently). Maybe I didn't explain this clearly enough. Let me write some quick pseudocode: class Catalog (Persistent): finished_changes = None # Mapping: {path -> (object, adding)} unfinished_changes = None # Same as above tid = None # Transaction ID def catalogObject(self, ob, path): unf = self.unfinished_changes if unf is None: self.unfinished_changes = unf = {} unf[path] = (ob, 1) def uncatalogObject(self, path): unf = self.unfinished_changes if unf is None: self.unfinished_changes = unf = {} unf[path] = (ob, 0) def searchResults(self, ...): self.finishChanges() # ... Perform search ... return results def finishChanges(self): unf = self.unfinished_changes if unf is not None: fin = self.finished_changes if fin is None or self._p_serial != self.tid: # Create finished_changes if not yet created # and clear it if we're in a different transaction # from the last time finished_changes was changed. self.finished_changes = fin = {} self.tid = self._p_serial for path, (ob, adding) in unf.items(): if adding: self.addToIndexes(ob, path) else: self.removeFromIndexes(path) fin[path] = (ob, adding) self.unfinished_changes = None def __getstate__(self): # Called during transaction commit. self.finishChanges() return Persistent.__getstate__(self) def _p_priority(self): # Causes this object to be added to the *top* # of the list of objects to commit rather than the # bottom. (Just an idea.) return 1 def _p_resolveConflict(self, old, committed, newstate): ''' Apply the changes in self.finished_changes to committed and return the result. ''' This does mean that _p_resolveConflict() might be called frequently, but (potentially) it would never fail because of conflicts. Now, this doesn't provide any automatic cataloging, which is what I think you're suggesting. I think automatic reindexing, a good idea, is mostly independent of bulletproofing and lazifying the catalog. To achieve automatic indexing, I was thinking that a special attribute would be added to cataloged objects. It would contain the OIDs of the catalogs interested in the object. Transaction.register() would look for this attribute and invoke catalogObject(). Of course, that wouldn't quite work because the object might change again within the transaction and the transaction manager wouldn't be told about the second and further changes. But I'm sure there's a good way to compensate for this, such as making the catalog scan for later changes before calling searchResults(). (cPersistence might need to assist.) Shane

1 0

Property Storage
by Chris Withers 07 Jun '01

07 Jun '01

Hi, If I change one property on, say, a DTML Document, does that store a whole new copy of the document in the ZODB? If not, then how are properties stored? Is so, then how about storing properties in their own mini-class that just subclassed Persistent, so each property got its own pickle jar? What do people think/know? cheers, Chis

2 1

xt_objects, and weird problems with properties
by tav 07 Jun '01

07 Jun '01

i am encountering some rather bizarre problems with 'properties' on xt_objects, which are effectively fancy folderish DTML Documents. the problems are two fold... - i call manage_changeProperties on an xt_object within other xt_objects, and at times, it would change the same property, e.g. xt_options, on all the other xt_objects in the same container! this would be magically rectified when i restart the zope server! - the second problem is of a different nature, it's to do with 'Date properties'. i have several date properties set by dtml when an object is created, e.g. xt_expiration_date. however, when i manually change a date property through manage_propertiesForm, it suddenly stops being a date property, e.g. if set through DTML, i can do <dtml-var "xt_expiration_date.year()"> but, i get an attribute error on year, if i change it manually... the code for xt_objects can be found at http://mu2.espnow.com/~zope/xt_object.py and any help would be appreciated. -- best regards, tav tav(a)espnow.com

1 0

Bulletproof ZCatalog proposal
by Shane Hathaway 07 Jun '01

07 Jun '01

I have written a proposal. http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog Could it be that we're involved in yet another Battle of Fredericksburg and we're trying to save innocent ZCatalogs from a ZODB conflict? Nawww... ;-) Shane

7 15

DBObjects 1.1.0b1 (with volatile support)
by Stephan Richter 07 Jun '01

07 Jun '01

Hello everyone, in my development of making SmartObjects a reality, I have implemented the 'isVolatile' attribute into DBObjects. If an object is volatile, it is not saved in the ZODB, but is created on run time. Thanks a lot Jonathan; without LocalFS as my template I could have not done it! ALSO, a lot of thanks to bluedynamics.com, which sponsored this particular development!!! I just put the latest package on the iuveno demo server: http://demo.iuveno-net.de/iuveno/Products/DBObjects I tagged this version 1.1.0 beta 1, since I am sure there are little bugs left due to huge code changes. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

1 0

mxDateTime-based Zope DateTime module
by Stephan Richter 07 Jun '01

07 Jun '01

Hello everyone, after I got finally frustrated enough with the current implementation of the Zope DateTime module, I decided to write a wrapper for mxDateTime. I checked the license, and the eGenix Public License is GPL compatible, so that we can use it for Zope now. For more details, see http://www.lemburg.com/files/python/mxDateTime.html. You can find the first version of the new DateTime module here: http://www.zope.org/Members/srichter/Products/DateTimeNG Currently, it has a problem with ZCatalog. If you create a catalog and then restart Zope, you get a nasty setstate error: 2001-06-07T04:54:40 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\000\000 \015' Traceback (innermost last): File /opt/devel/dev11480/lib/python/ZODB/Connection.py, line 533, in setstate SystemError: Failed to import class localtime from module __main__ (This is abbreviated debug output from the console.) Since I would like to see this new module in the Zope core ASAP (best in Zope 2.4), I wanted to ask you guys, whether you could have a look at this problem, since I do not know much about the Catalog and the entire ZODB pickle/unpickle process. Furthermore, I would love to hear your comments and ideas. With mxDateTime we can do much more now and have many more possibilities. The current version of the new DateTime module handles most of the old API functions correctly. Only some timezone issues are left open, but using the existing time zone mappers this should be no problem. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

3 6

Using Threads in Zope-Product
by Ulrich Eck 07 Jun '01

07 Jun '01

Hi zopistas, I currently work on a PythonProduct called JobManager. The purpose of this Product is, that one can define a hierachical set of PythonScripts (Jobs with SubJobs) that are executed in seperate Threads by call or scheduled. This is intended for use with expensive Database-Update or my ServiceManager (XML-RPC Server/Client) which need to much time to complete, that a user can't / doesn't want to wait for completion. Now there is some trikyness in programming Threads in zope .. because I wanted the thread-instances to be accessible throug zope as long as they are running - ZODB uses the module thread (start_new_thread, aquire/release_lock) - Scheduler (i found it in DC-CVS) is probably not finished and uses thread as well. the thread instance is not accessible from Zope as far as i can see - ZExternalNewManager uses the module threading (Thread(...)) the thread-instance is stored as volatile attribute (_v_threadinstance) Using the threading library would be most convinient but the Objects from threading are not pickable. I need Locks and would like to have Conditions to control the behavior of the JobManager, so I tried to make a copy of threading and added Persistence .. (derived all classes from ZODB.Persistent, but doesn't work) with no success. Is it basically possible .. does it make sense to store the instance of a Thread as an attribute of a ZODB-stored Object ??? If yes .. what changes are neccesary to make threading persistant If no .. has anybody else done such a thing with success ?? any comment welcome thanks Ulrich Eck net-labs

1 0

RE: [Zope-dev] mxDateTime-based Zope DateTime module
by Stephan Richter 07 Jun '01

07 Jun '01

>We at one point were fiddling with mx from eegenix, for psycopgDA. We found >out the hard way that the mx.h headers in the DateTime were being put in a >funny place. Perhaps that may give you a clue. I hope you are going to use mxDateTime for a new PostGreSQL DA. This would be for me the MAIN reason to choose it, since I really want DateTime objects returned, not strings. For the Zope DateTime module: Since we are working on the Python level I thought it would be no problem on the C level. Unfortunetely I do not know enough about the Python C API to check this. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

1 0

A simple dtml-if question...
by Jeff Nielsen / UgoFast 07 Jun '01

07 Jun '01

How do I construct a dtml-if statement with two conditions joined by "and" logic? I want to do something like this: <dtml-if expr="LoginResults=='Pass'" .and. expr="PATH_INFO=='/'"> Jeff Nielsen / UgoFast http://www.UgoFast.com Jeff(a)UgoFast.com

2 2