November 2001 - Zope-Dev

Catalog improvements
by Wolfram Kerber 01 Dec '01

01 Dec '01

Hi, i'm currently working on a product that allows to attach relational information to zope-objects. It works quite well so far, but to further enhance it i need to make some changes to the Catalog. I could perhaps implement it as a separate product, but i strongly feel that those changes are best applied to the Catalog itself, as they are of general use (i think) and involve a lot of changes to the inner workings of the Catalog. In particular i need the following: - named/stored queries these are precompiled queries, so they can be executed without parsing and are easily cacheable i.e. similar to what is implemented in CMFTopic, but stored in the Catalog and a bit smarter - caching support - unions and intersections sub-queries (i.e. queries that are directed at a certain index) should be more flexibly combineable I searched this mailing-list as well as zope.org to get an idea about what has already been discussed and requested, and there seems to be some interest in improving the Catalog. Some people even seem to have worked on this, perhaps they could give an update on this? Possibly i don't have to write everything from scratch... I would have put this into a proposal, but there already are two proposals that deal with the features i want, one is dedicated to unions/intersections, the other (TopicIndexes) to performance issues (i dont't know what's the status of these though, especially the first one is rather old), and i don't want to hijack them without asking. As so often i will need to complete my current project first, but would then like to help in improving the Catalog for a more general use. So, if there is interest, i would propose to collect some ideas and comments about how a better Catalog should look like, how it could be best implemented and how to organize this effort (with respect to the already existing proposals). -- Wolfram Kerber Gallileus GmbH http://www.gallileus.info/

11 26

changing a Fishbowl Proposal's state
by emf 30 Nov '01

30 Nov '01

Hi, I want to change the "Awaiting Resources" state of the SiteAccessUsabilityEnhancements to a real project ... I read all the docs i could find on the process, but I can't see what happens to move it from awaiting to actual... -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"

2 1

FW: Zope & optimistic transactions.
by Clark OBrien 30 Nov '01

30 Nov '01

> -----Original Message----- > From: Clark OBrien > Sent: Monday, November 05, 2001 7:14 AM > To: 'chrism(a)zope.com'; 'k_vertigo(a)yahoo.com' > Cc: 'zope(a)zope.org' > Subject: Zope & optimistic transactions. > > > Chris, > I set up a test harness to exercise zopes optimistic transaction > management. > My test immediatly caused a ZODB exception. > > I am running zope 2.42. on win 2k, the scripts are attached. > Results below: > > As you recall I posed the following question: > > What if you had a directory structure like: > Folder1 > Folder-2 > Folder-3 > ... > .. > Folder-n > Each folder had an attribute foo and there were two scripts, script1 and > script2. > script1 modified foo on one Folder only while script2 traversed all the > folders modifying the attribute foo on each one of them. > Would the script2 ever commit while the fist while script1 was > continuously called. This is interesting because a call to script2 would > never finish before several calls to script1 finished. > > I set up a simple test with only 10 folders. I then wrote the script below > changeLevel2 that is my scri1 above and changeFolders that is my script2 > above. > I ran changeLevel2 in a loop using the following code: > ----------------------------------------script---------------------------- > ------------------- > import urllib > params = urllib.urlencode({'theText': 'Vitamin D'}) > while 1: > f = urllib.urlopen("http://localhost:8080/Test/changeLevel2?%s" % params) > print f.read() > -----------------------------------------script--------------------------- > --------------------- > > > I then ran the script changeFolders from my browsers. > The result was the following error message: > > ------------------------------------------------------------ > ZODB.POSException.ConflictError > > Sorry, a site error occurred. > > Traceback (innermost last): > File C:\zope\lib\python\ZPublisher\Publish.py, line 223, in > publish_module > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 195, in publish > ---------------------------------------------------------- > > > > <<scripts.txt>>

7 9

FW: Zope & optimistic transactions.
by Clark OBrien 30 Nov '01

30 Nov '01

[Clark OBrien] I think I was sending to zope-dev(a)zope.COM my mistake- but an easy one to make. > From: Clark OBrien > Sent: Monday, November 05, 2001 7:14 AM > To: 'chrism(a)zope.com'; 'k_vertigo(a)yahoo.com' > Cc: 'zope(a)zope.org' > Subject: Zope & optimistic transactions. > > > Chris, > I set up a test harness to exercise zopes optimistic transaction > management. > My test immediatly caused a ZODB exception. > > I am running zope 2.42. on win 2k, the scripts are attached. > Results below: > > As you recall I posed the following question: > > What if you had a directory structure like: > Folder1 > Folder-2 > Folder-3 > ... > .. > Folder-n > Each folder had an attribute foo and there were two scripts, script1 and > script2. > script1 modified foo on one Folder only while script2 traversed all the > folders modifying the attribute foo on each one of them. > Would the script2 ever commit while the fist while script1 was > continuously called. This is interesting because a call to script2 would > never finish before several calls to script1 finished. > > I set up a simple test with only 10 folders. I then wrote the script below > changeLevel2 that is my scri1 above and changeFolders that is my script2 > above. > I ran changeLevel2 in a loop using the following code: > ----------------------------------------script---------------------------- > ------------------- > import urllib > params = urllib.urlencode({'theText': 'Vitamin D'}) > while 1: > f = urllib.urlopen("http://localhost:8080/Test/changeLevel2?%s" % params) > print f.read() > -----------------------------------------script--------------------------- > --------------------- > > > I then ran the script changeFolders from my browsers. > The result was the following error message: > > ------------------------------------------------------------ > ZODB.POSException.ConflictError > > Sorry, a site error occurred. > > Traceback (innermost last): > File C:\zope\lib\python\ZPublisher\Publish.py, line 223, in > publish_module > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 200, in publish > File C:\zope\lib\python\ZPublisher\Publish.py, line 195, in publish > ---------------------------------------------------------- > > > > <<scripts.txt>>

1 0

Zope has been Hijacked! Save Zope!
by Clark OBrien 30 Nov '01

30 Nov '01

Thanks Andrew for a heartfelt description of what is happening here. It is clear that unlike the other freeware products like Lenux, JBoss.., Zope has lost all of the advantages of being a freeware product. What I find sad is that the extreme commercialization of Zope is hurting Zope- this discussion list is censored in a way that would not be allowed for most commercial products. I posted a serious bug- Zope throws an exception after trying to resolve a transaction conflict three times. The discussion was quickly moved line and I was told this is not a problem- Not a problem? Give me a break!! This nearly killed my application and cost me several weeks of work. Those who know of these problems can write clean applications but these issues are kept strictly confidential. To the *TRUE* open source community I would just say let us reclaim Zope-even if it means branching. Clark

5 5

Dataskin Zclass + Folder subclassing problem
by Jean Lagarde 30 Nov '01

30 Nov '01

Hi all, A ZClass inheriting from both DataSkin and Folder seems to work as expected (so much has been discussed in other messages, at least with ObjectManager). However, instead of inheriting directly from DataSkin, I want to inherit from another Zclass which is itself based on DataSkin, i.e. (not showing Zobjects): DataSkin ZClass1 Folder | \ / | \ / v v v ZClass1 ZClass2 After its creation, the new Zclass ZClass2 seems to have some management issues: - The views are initialized to those of ZClass1; no big deal, for now, I just added a new view tab named Contents for manage_main - When I create an instance of ZClass2 (in a Folder w/Customizer Support), the instance does show its Contents tab, but it does not quite know it's folderish: - It does not show in the left pane of the ZMI - If I add an object from the contents tab interface of the instance, say a dtml method, it adds OK, but does not show in the contents tab (the contents view is always empty no matter what I add) - The objects I added are there; I can traverse to them and their management interfaces, and I have also checked the ZODB directly using the wonderful pyTree.py. I'm afraid that I know just enough about Zope to be dangerous ;-) I basically just have the time to learn about the stuff that I need to get the job done, and I'm sure that the current version of what I'm working on will need some refactoring later on. So I have two questions: 1) Anybody can think of a quick fix to get the folderish behavior working as it should? 2) In its current state (if there is no quick fix), ZClass2 seems usable enough for my needs; I just need to add a couple of objects for each instance, and I can reach their management screens through explicit traversal. So I'm tempted to plug along and keep on experimenting with that setup for now. Any other more important consequences that I'm missing that should have me fix this more adequately before I proceed? Cheers, Jean

3 4

Re: [Zope-dev] Open Letter to zope-dev
by Lennart Regebro 30 Nov '01

30 Nov '01

From: "Steve Alexander" <steve(a)cat-box.net> > Does the fishbowl process address this for you? > > http://dev.zope.org/Fishbowl/Introduction.html I'm aware of the fishbowl process.

3 2

Fw: [Exuserfolder-devel] Zope 2.5b1 release
by Dario Lopez-Kästen 29 Nov '01

29 Nov '01

I thought this might be intresting for discussion on zope-dev as well... /dario ----- Original Message ----- From: "Andrew Kenneth Milton" <akm(a)theinternet.com.au> To: "Andrew Kenneth Milton" <akm(a)theinternet.com.au> Cc: <exuserfolder-devel(a)sourceforge.net> Sent: Thursday, November 29, 2001 8:45 AM Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release It has been pointed out that perhaps the dripping sarcasm drowned out the acutal points of the email, sorry I was particularly pissed off at how half-assed it all was. If you are writing a product that needs to create a user, you go look in User.py and find out what the API since that tends to be the only place the API is documented. If you look at how UserFolder is implemented; a) The change to manage_* seems to be completely arbitrary, since we already had _do* methods that meant you didn't have to call manage_users with fake submit buttons. So what is the point of having manage_ ? b) manage_* methods usually indicate web callable methods, which these clearly aren't (no docstring, no REQUEST parameter). In fact they don't return a status at all, so they seem to doubly useless. c) If it's an internal API for applications then the methods should probably be protected by being prefixed with an _ to indicate they're not for calling from the web or from within Documents/Templates. d) Even if you conformed to the API by calling e.g. manage_addUser() this seemed to be incorrect, since it didn't do things like encrypt the password. This meant you would have to either a) encrypt the password yourself (*very bad for XUF*), or b) call _addUser() which is not part of a defined API but looks like it should be (i.e. manage_addUser and _addUser seem to be reversed in functionality). ii) This is compounded by the fact you would have to query the UserFolder itself to find out if you should be encrypting passwords (what no UserFolder capability API?). e) s/_do/manage_/ doesn't constitute a new API. It's just the old one with the names changed. f) We've done a lot of work to make a flexible UF product that is I18Ned (well -able), and they still use the value of the submit button. I would have expected to see an alternative manage_users called from the ZMI that behaved much better, with manage_users calls raising warnings. g) Someone got paid to do it, and that just pisses me off, given the quality of the stuff we release for free (and I'm still looking for a job btw d8). We're not perfect, the 0.10.1 release shows that, but, at least we spent more than three minutes including thinking time on it, and I at least try not to change things just for the sake of it. Anyway. In case you were wondering what the previous email meant, there's the actual meaning d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm(a)theinternet.com.au| _______________________________________________ Exuserfolder-devel mailing list Exuserfolder-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel

5 7

ZODBC bug
by mike hong 29 Nov '01

29 Nov '01

I found ZODBC bug at max_rows. file name: db.py line: 230 Current version is getting all rows regardless of max_rows. Fixed version is getting rows until rows are smaller than max_rows. Current version: while status==SQL_SUCCESS: ..... r.append(rd) status=SQLFetch(stmt) ..... Fixed version: cnt = 0 while status==SQL_SUCCESS and cnt < max_rows: ....... r.append(rd) cnt = cnt + 1 status=SQLFetch(stmt) ....... Have a nice day !!!!!!

2 1

User folders, access rights, security, collector item 47
by Brad Clements 29 Nov '01

29 Nov '01

Sorry to post here. I posted last week on the zope list about what appears to be a new/strange security related problem in 2.4.3 I thought it was a problem in LdapUserFolder, but jens spent more time debugging than I did and he feels it's somewhere in the Zope security machinery. http://collector.zope.org/Zope/47 Is it security related when security doesn't do what you want (though nothing has been exposed, rather, what we want exposed isn't)? I'd try to tackle this myself, but I really have no idea where to start. I know everyone is busy, but I was wondering if anyone else has been able to reproduce the condition so that we can say for certain if its a bug, or a mis-configuration. Thanks, Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements

1 0