[Zope-dev] What can you do with FSDump?
I installed FSDump and created a file system dump. Then do I follow the normal rules of Python product development? What are some of the various ways I can use it? TIA -Jimbo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A way to check what products are installed?
Quick hack: -- Andy McKay, Developer. ActiveState. - Original Message - From: "Morten W. Petersen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 19, 2000 9:36 PM Subject: [Zope-dev] A way to check what products are installed? > Is there a clean way to do this (preferrably from both Python and > DTML) ? > > Thanks. > > -Morten > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book Question: 'context' doesn't work in PythonMethods
Chris Gray wrote: > > I tried following one of the Zope Book examples to no avail. > > >From the scripting chapter: > > "Since Python Methods are bound the Zope objects, you can get access to Zope > objects via the context parameter. For example, this methods returns the > number of objects contained by a given Zope object: > > Method id: numberOfObjects > Parameters: > > return len(context.objectIds())" > > I just get a Name Error on context and if I add context as a parameter I > just get told that the parameter was omitted from the request. This works, > however: > > Method id: numberOfObjects > Parameters: self > > return len(self.objectIds()) > > Am I missing something? Is this because Amos and Michel seem to be using > 2.2.3 and I'm using 2.2.2? They are using an unreleased version of the Python Methods product. AFAIK the only thing holding up the release of the new Python Methods is the renaming. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Conflict Errors
It happens when more than one thread tries to modify the same object in storage at the same time. It's Zope's equivalent of record-locking... It's normal. There's no corruption or anything, it's telling you that it avoided a write that might have caused problems. Zope tries three times to retry the write. If the object is still locked by another database connection after three writes, it propogates the exception up to the app level. That's the error you see. Careful application coding can reduce the chance of conflict errors. I've seen conflict errors pop up a lot when the catalog is used for whatever reason, especially with catalogaware. I bet it happens on a catalog write for you. I think this may have something to do with the current BTree implementation's propensity to write child-parent relationships all the way up and down the tree every time a node changes. I know your next questions are going to be "why?" and "how do I fix it?" and "why don't you fix it?". Chris Petrilli did some work on the catalog for 2.2.3 that might have a positive impact. The catalog is (I think) being actively worked on if you can nail it down some, it'd probably be helpful to figure out when the conflicterror occurs and pass it along to Chris in the collector. Besides that, I don't have any specific hints for you, besides waiting for the new BTree implementation. The answer to "when?": I have no idea. HTH, C - Original Message - From: "Chris Withers" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 20, 2000 10:46 AM Subject: [Zope-dev] Conflict Errors > Hi, > > Whenever there's a lot of writes and the occasional read going on, we > get the following error: > > 2000-11-19T16:03:44 INFO(0) Z2 CONFLICT Competing writes at, > /aFolder/anObject > Traceback (innermost last): > File D:\Program Files\Zope\lib\python\ZPublisher\Publish.py, line 175, > in publ > ish > File D:\Program Files\Zope\lib\python\Zope\__init__.py, line 235, in > commit > File D:\Program Files\Zope\lib\python\ZODB\Transaction.py, line 251, > in commit > > File D:\Program Files\Zope\lib\python\ZODB\Connection.py, line 267, in > commit > ConflictError:y > > Can anyone shed any light on: > -what this means > -how bad it is > -how we can make it stop happening > > cheers, > > Chris > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book Question: 'context' doesn't work in PythonMethods
On Mon, 20 Nov 2000, Shane Hathaway wrote: > They are using an unreleased version of the Python Methods product. > AFAIK the only thing holding up the release of the new Python Methods is > the renaming. (I believe the version in question is available from the public CVS repository, as the Products/DC/PythonMethod module.) (Ken) [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Book Question: 'context' doesn't work in PythonMethods
I tried following one of the Zope Book examples to no avail. >From the scripting chapter: "Since Python Methods are bound the Zope objects, you can get access to Zope objects via the context parameter. For example, this methods returns the number of objects contained by a given Zope object: Method id: numberOfObjects Parameters: return len(context.objectIds())" I just get a Name Error on context and if I add context as a parameter I just get told that the parameter was omitted from the request. This works, however: Method id: numberOfObjects Parameters: self return len(self.objectIds()) Am I missing something? Is this because Amos and Michel seem to be using 2.2.3 and I'm using 2.2.2? adTHANKSvance Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Conflict Errors
Hi, Whenever there's a lot of writes and the occasional read going on, we get the following error: 2000-11-19T16:03:44 INFO(0) Z2 CONFLICT Competing writes at, /aFolder/anObject Traceback (innermost last): File D:\Program Files\Zope\lib\python\ZPublisher\Publish.py, line 175, in publ ish File D:\Program Files\Zope\lib\python\Zope\__init__.py, line 235, in commit File D:\Program Files\Zope\lib\python\ZODB\Transaction.py, line 251, in commit File D:\Program Files\Zope\lib\python\ZODB\Connection.py, line 267, in commit ConflictError:y Can anyone shed any light on: -what this means -how bad it is -how we can make it stop happening cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Two glaring omissions
Toby Dickenson wrote: > > On Thu, 16 Nov 2000 19:51:24 -0500, Tres Seaver <[EMAIL PROTECTED]> > wrote: > > >Toby Dickenson <[EMAIL PROTECTED]> wrote: > > > >> On Tue, 14 Nov 2000 15:39:59 -0500, Shane Hathaway > >> <[EMAIL PROTECTED]> wrote: > >> > >> >> 2. The ability to rename properties after instances of the classes have > >> >>been created (and have the data in those fields preserved) > >> > > >> >This is also more difficult than it sounds. You'd have to either scan > >> >through the entire ZODB and modify class instances or associate > >> >properties with a magical, unchanging ID. The latter solution is dead > >> >wrong, but the first is actually kind of interesting. If there were a > >> >separate index for each object type in the ZODB, it would be possible. > >> >In fact, when ZODB is running from a relational database, there is > >> >indeed a way to do that. Hmmm... > >> > >> Or if your ZClass has a python base class, then a __setstate__ method > >> could be added to do the same thing incrementally. Like all changes to > >> a Python base class, this requires restarting the server. > > > >Correct in theory, but broken in practice: if you make your ZClass > >persistent (i.e., you leave checked the "Include standard Zope > >persistent object base classes?" checkbox on the "Add ZClass form), > >then Persistent will be the first base class in the list, and *your* > >'__setstate__' will never be called! > > Some more theory thats not backed up by any practical experience in > this area: Would it be sufficent to create a base class that derives > from Persistent and then uncheck the box? or does that checkbox get > involved in some other magic? Here's an idea... what we might look at is adding another method call to ZODB.Connection.setstate(). In fact, we could cause it to call the new method on behalf of every base class. It would work well, I think, but I still don't know how much merit this idea has. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Two glaring omissions
On Mon, 20 Nov 2000, Toby Dickenson wrote: > On Thu, 16 Nov 2000 19:51:24 -0500, Tres Seaver <[EMAIL PROTECTED]> > wrote: > >Correct in theory, but broken in practice: if you make your > >ZClass persistent (i.e., you leave checked the "Include > >standard Zope persistent object base classes?" checkbox on the > >"Add ZClass form), then Persistent will be the first base > >class in the list, and *your* '__setstate__' will never be > >called! > > Some more theory thats not backed up by any practical > experience in this area: Would it be sufficent to create a base > class that derives from Persistent and then uncheck the box? or > does that checkbox get involved in some other magic? Actually, I was mistaken. I was spelunking through the ZClass code (.../lib/python/ZClasses/*.py) this weekend, working on my filesystem dumper; *all* ZClasses declare ZClasses.ZClass.PersistentClass as the first class in their base class list; this class derives only from ExtensionClass.Base, and not from Persistence.Persistent; I don't any longer know *why* my ZClasses' '__setstate__' would not be called! The 'zope_object' flag passed to 'manage_addZClass' causes OFS.SimpleItem.Item to be *appended* to the base class list (so it should have no effect on the '__setstate__' lookup). Tres. -- === Tres Seaver[EMAIL PROTECTED] Digital Creations "Zope Dealers" http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZMySQLDA transaction issues.
We were chatting a while back about how to handle the MySQL issue of support/non-support for transactions, with the dominant suggestion at the time being two DAs. I just got done talking with Michael Widenius (Monty of MySQL fame) and he offered to add a warning on rollback if the table doesn't support transactions. So what I'm going to do is this, unless anyone can raise a beefy suggestion. 1) Actually get off my ass and incorporate all of adustman's MySQLdb changes into my ZMySQLDA. :) 2) Make transactions un-supported until the release of MySQL that contains the warning. Since the 3.23 line is pre-release, there shouldn't be any issues with people using a version of MySQL that supports transactions but not being able to upgrade to one that ZMySQLDA supports (you should never be that tied to a pre-release version of anything.) 3) For all MySQL versions that we don't 'officially' support as having transactions, throw an exception if a rollback is attempted. 4) Include a config option to turn off the exceptions. I believe we should be able to keep a simple, and single, ZMySQLDA this way. But please, shoot holes in the plan for me. Thanks, Monty ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Two glaring omissions
On Thu, 16 Nov 2000 19:51:24 -0500, Tres Seaver <[EMAIL PROTECTED]> wrote: >Toby Dickenson <[EMAIL PROTECTED]> wrote: > >> On Tue, 14 Nov 2000 15:39:59 -0500, Shane Hathaway >> <[EMAIL PROTECTED]> wrote: >> >> >> 2. The ability to rename properties after instances of the classes have >> >>been created (and have the data in those fields preserved) >> > >> >This is also more difficult than it sounds. You'd have to either scan >> >through the entire ZODB and modify class instances or associate >> >properties with a magical, unchanging ID. The latter solution is dead >> >wrong, but the first is actually kind of interesting. If there were a >> >separate index for each object type in the ZODB, it would be possible. >> >In fact, when ZODB is running from a relational database, there is >> >indeed a way to do that. Hmmm... >> >> Or if your ZClass has a python base class, then a __setstate__ method >> could be added to do the same thing incrementally. Like all changes to >> a Python base class, this requires restarting the server. > >Correct in theory, but broken in practice: if you make your ZClass >persistent (i.e., you leave checked the "Include standard Zope >persistent object base classes?" checkbox on the "Add ZClass form), >then Persistent will be the first base class in the list, and *your* >'__setstate__' will never be called! Some more theory thats not backed up by any practical experience in this area: Would it be sufficent to create a base class that derives from Persistent and then uncheck the box? or does that checkbox get involved in some other magic? Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
