- Zope-Dev - Zope lists

Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
by Dennis Allison 20 Dec '05

20 Dec '05

The interaction between sessions, conflicts, and persistence is a bit confusing. I am still trying to understand the code in depth. One thing is for sure, request.SESSION and/or request['SESSION'] must be persistent for things to work. Mutable objects in the session variable set (dictionaries and lists) have to be handled specially to get the persistence machinery to recognize they have been changed. In this case, I am trying to ensure that the session variables get identified as persistent. My question is whether using update (an implicit assignment) triggers the persistence mechanism. It is the moral equivalent of writing request['SESSION']['alpha'] = 'a'B request['SESSION']['beta'] = 'b' but I am unsure whether the persistence mechanism will recognize it as such. Doing session variable initialization in a Script(Python) object has a downside because one cannot set a _p_changed attribute and so must rely on the assignment paradigm. Perhaps the interface should be in a Product or External Method which is less constrained. Anyhow, David, thanks for the assist. On Mon, 19 Dec 2005, David H wrote: > Dennis Allison wrote: > > >Chris McDonough identified a persistence problem with the routine(s) that > >manage sessions variables. (Thanks Chris) I have put the correction in > >place which resolved some (but not all) of the problems. > > > >There are still problems which are apparently due conflicts in accessing > >the session variables. To minimize frequency of conflicts, I am rewriting > >several routines using Dieter's rules of the thumb (Thanks Dieter). > > > >One routine being modified is a Script(Python) that initializes a number > >of session variables. I am collecting the session values in a dictionary > >and then use update to set their value, for example: > > > > s = {} > > s['alpha'] = 'a' > > s['beta'] = 'b' > > request['SESSION'].update(s) > > > >Is the persistence machinery smart enough to detect this as a change? I > >suspect that it has to be flagged since the assignment won't be seen. > >Usually this means setting the _p_changed=1 attribute, but it is not clear > >to me where to set it in this particular context. > > > Dennis, > > Did you means request['SESSION']['someDictionary'].update(s)? > Anyway your idea seems correct - The SESSIONS chapter (at least on > plope.com) addresses SESSION "staleness" and mutable objects. > > 1) someDict = SESSION['someDict'] > 2) someDict['someKey'] = "newValue" > > But (2) does not guarentee that a subsequent lookups like: > SESSION['someDict'] will return "newValue". > > But this WILL: > 3) SESSION['someDict'] = someDict. > > Which looks like your example. How this connect to your primary issue: > *conflicts* is not clear to me. :-\ > > David > > --

2 1

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2342 Blamelist: shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Re: Unit Test Failures
by Tres Seaver 20 Dec '05

20 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: > >>Benji York wrote: >> >>>The Zope2 unit tests have been failing for some time on >>>buildbot.zope.com. Looks like a Five-related problem: >>>http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/10… >> >>The failing test is a functional test, not a unit test; I don't run >>them by default when I check in. > > Actually, I put this particular test (functional.txt) on level=2 because it would fail > when run together with other Five tests. It passes fine when run by itself. This test > exists identically in Five 1.2 (based on Zope 2.8) where it passes just fine when run > together with other tests and by itself. During the hot phase of making the deadline on > November 1st, I decided that this wasn't a big issue and could be resolved during the > beta phase (after all, the test passes by itself). I obviously forgot to look into it > again, but then again, I still don't know what the heck is wrong with this. > >> I see a couple of problem points: the biggest is the use in the >> output of 'checkSiteManager.html' of a repr'ed dict, which might >> render differently between different machines (or even the same >> machine across Python versions). > > Well, if you look closer you find that it uses pprint.pformat which always outputs the > same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. >> This is a classic case where the "doctest" does *not* provide >> clarity over a "traditional" 'unittest' style test, IMNSHO. > > Comparing dictionaries is not trivial in classic javiotic tests, either. Using pprint is > actually quite an elegant way, I think. But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. >>I'm not sure what it is testing, either; > > It's testing how local site managers get found during traversal and how that affects > component lookup of e.g. views (depending on which site is traversed, you would find > local components or not). OK, thanks! Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDptfi+gerLs4ltQ4RAtfkAKCiJLa+s+8GaNxew9DcIPWrbw7qXgCeNaSj csBJ641nurB0xPwBu6xLByY= =juKw -----END PGP SIGNATURE-----

6 15

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2341 Blamelist: shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2340 Blamelist: andreasjung BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2339 Blamelist: andreasjung BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2338 Blamelist: andreasjung,chrisw,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2337 Blamelist: andreasjung,chrisw,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Re: sessions in the presence of conflicts
by Florent Guillaume 20 Dec '05

20 Dec '05

[Using zope-dev@ instead of zope@] Dennis Allison wrote: > A more session-friendly conflict resolution might use: > > 1. if any of the states are invalid (that is, has a key '_invalid') > return the invalid state. > > 2. if any any of the states attributes ['token','id','_created'] > differ then there is a conflict, raise the conflict exception. > > 3. order the newState and savedState by modification time (or if that > cannot be computed, by access time). > > 4. any key appearing in oldState's dictionary but not appearing in > both savedState and newState should be removed from all. This > corresponds to a key-value pair being deleted in one of the > transactions. Insertions will be managed automatically by > the updates. > > 5. beginning with the oldest, update oldState dictionary of key-value > pairs using the dictionary part of newState and savedState. Return > oldState. > > This does several things. First, it captures independent key-value > changes made in both potentially conflicting transactions. Second, it > provides a reasonable ordering for multiple (potentially conflicting) > key-value pair updates. Third, it manages insertions and deletions to the > session variable set in the presence of conflicts. > > Does this make sense? I have yet to figure out how to map a > TransientObject "state" back to the object it represents, but it clearly > is possible. I certainly makes sense from a high level description, but the devil is in the details. I'd be interested in looking at it if you code something. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

5 7

Modifying a ZPT state based on a certain parameter
by Takahashi, Michael 20 Dec '05

20 Dec '05

Hi guys, I am running on Zope 2.7.6 with Plone 2.0.5. I am currently building a dynamic application using MySQL as the backend database. I'd like to be able to change a ZPT's state based on a parameter passed by the db. For example, I have a ZPT that displays information for a particular course. However, if this courses "active" field is set to NO, then I would like to be able to have the ZPT's state be visible. If the courses "active" field is set to "yes" then I would like to modify the state so that the ZPT is published. I'm thinking I'd probably have to use the wf_tool in conjunction with portal_workflow? A call similar to something like so: tal:condition="python:records.active=='yes'" ...then implement the necessary call to modify the workflow and make the ZPT published and vice versa. Any help is greatly appreciated. Thanks, Mike

2 1