Squishdot Error on Zope 2.6.0
Hi, I install new Zope-2.6.0 on FreeBSD 4.6.2 and add Squishdot 1.4.1 products with no error message found in control pannel but when I add new squishdot site or zexp from my backup import a message show : Error Value: list.index(x): x not in list Site Error Log at /error_log Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.Squishdot, line 49, in manage_addSquishdot Module Products.Squishdot.SquishSite, line 182, in __init__ Module Products.Squishdot.SquishSite, line 155, in _buildIndexing Module Products.ZCatalog.Catalog, line 208, in delColumn ValueError: list.index(x): x not in list Do you have any suggestion to solve this problem? Thank, Viriya
the squishdot code tries to delete a catalog metadata column without even checking if this column is in the catalog at all. bad coding. i suggest you get in touch with the maintainer (i believe it is chris withers) and describe the problem to him. jens On Sunday, Oct 27, 2002, at 15:49 US/Eastern, viriya wrote:
Hi, I install new Zope-2.6.0 on FreeBSD 4.6.2 and add Squishdot 1.4.1 products with no error message found in control pannel but when I add new squishdot site or zexp from my backup import a message show : Error Value: list.index(x): x not in list Site Error Log at /error_log Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.Squishdot, line 49, in manage_addSquishdot Module Products.Squishdot.SquishSite, line 182, in __init__ Module Products.Squishdot.SquishSite, line 155, in _buildIndexing Module Products.ZCatalog.Catalog, line 208, in delColumn ValueError: list.index(x): x not in list Do you have any suggestion to solve this problem? Thank, Viriya
Jens Vagelpohl wrote:
the squishdot code tries to delete a catalog metadata column without even checking if this column is in the catalog at all. bad coding.
I don't really follow your logic. ZCatalog always used to create these indexes, how is it bad coding to always delete them? cheers, Chris
it's just that making assumptions about what the environment looks like is never a good idea. it is really easy on the other hand to add code that determines what indexes are really available or to surround the deletion code with try/except statements. it'll save you support questions in the long run. jens On Monday, Oct 28, 2002, at 08:25 US/Eastern, Chris Withers wrote:
Jens Vagelpohl wrote:
the squishdot code tries to delete a catalog metadata column without even checking if this column is in the catalog at all. bad coding.
I don't really follow your logic. ZCatalog always used to create these indexes, how is it bad coding to always delete them?
cheers,
Chris
Jens Vagelpohl wrote:
it's just that making assumptions about what the environment looks like is never a good idea.
If you made no assumptions, you'd write no code.
it is really easy on the other hand to add code that determines what indexes are really available or to surround the deletion code with try/except statements. it'll save you support questions in the long run.
...and if you write a try/except for every possible name or piece of code that may change in the future, you'll end up with an infinitely large piece of code. Sorry, your logic is flawed. This is just 'one of those things' that happens when people change code that other code relies on. Sadly, ZCatalog has been particularly prone to that over the years... cheers, Chris
On Mon, Oct 28, 2002 at 01:44:36PM +0000, Chris Withers wrote:
Jens Vagelpohl wrote:
deletion code with try/except statements. it'll save you support questions in the long run.
At least it would have saved all of us from this beginning flamewar ;-) Jerome Alet
Jens Vagelpohl wrote:
it's just that making assumptions about what the environment looks like is never a good idea.
If you made no assumptions, you'd write no code.
it is, especially in this case, easy to guard against changing environments.
it is really easy on the other hand to add code that determines what indexes are really available or to surround the deletion code with try/except statements. it'll save you support questions in the long run.
...and if you write a try/except for every possible name or piece of code that may change in the future, you'll end up with an infinitely large piece of code.
if you don't like try/except you can use the well-known catalog APIs for determining the IDs of metadata columns and indices.
Sorry, your logic is flawed. This is just 'one of those things' that happens when people change code that other code relies on. Sadly, ZCatalog has been particularly prone to that over the years...
you're correct, ZCatalog has seen many changes. but instead of giving up and hardcoding an expected environment just a couple more lines of code can go a long way towards ameliorating the impact of those changes. jens
Jens Vagelpohl wrote:
you're correct, ZCatalog has seen many changes. but instead of giving up and hardcoding an expected environment just a couple more lines of code can go a long way towards ameliorating the impact of those changes.
I'm with Jerome on this one, go bait somewhere else... Chris
On Mon, Oct 28, 2002 at 02:29:02PM +0000, Chris Withers wrote:
Jens Vagelpohl wrote:
you're correct, ZCatalog has seen many changes. but instead of giving up and hardcoding an expected environment just a couple more lines of code can go a long way towards ameliorating the impact of those changes.
I'm with Jerome on this one, go bait somewhere else...
too bad I fundamentally agree with Jens here ;-) theorically, what Jens says is better coding method. However we all know that the difference between theory and practice is that in theory there's no difference between theory and practice. that's why I perfectly understand that Chris doesn't really care about this : no-one makes perfect programs (Knuth excepted ?) bye, Jerome Alet
Jerome Alet wrote:
On Mon, Oct 28, 2002 at 02:29:02PM +0000, Chris Withers wrote:
Jens Vagelpohl wrote:
you're correct, ZCatalog has seen many changes. but instead of giving up and hardcoding an expected environment just a couple more lines of code can go a long way towards ameliorating the impact of those changes.
I'm with Jerome on this one, go bait somewhere else...
too bad I fundamentally agree with Jens here ;-)
theorically, what Jens says is better coding method.
Well, if you're both going to bait ;-) So, today catalog has a searchResults method, in two years time that may change so that only __call__ is supported. Does that mean I should write: try: results = self.catalog.searchResults(...) except AttributeError: print "catalog had no searchResults method!" results = [] ? ...but then what if AttributeError isn't what gets raised? So now I have to wrap every call in a bare try:.. except? I'll leave you to go through the archives to find out why that is totally abhorent ;-) The situation with catalog indexes is identical to this. When I wrote that code, it's what catalog did, there were no plans to change that and it didn't look like there ever would be (the current situation with searchResults now ;-). So, now things have changed. I get a few bug reports and change the code. Ironicly, this will probably be to exactly the code you guys are talking about, to maintain backwards compatability. But, I'm not gonna try and become psychic, and I wouldn't expect anyone else to, and I'm not gonna follow Jens suggested path which really does lead to writing an infinitely large piece of code at it's conclusion (what if the y['x'] syntax is deprecated in Python 10?) I'm also gonna stick to the old adage of KISS which also runs through XP, which has stood me in good stead and means I don't have to go crystal ball hunting (the magic ones are hard to find yaknow ;-) cheers, Chris
if you don't like try/except you can use the well-known catalog APIs for determining the IDs of metadata columns and indices.
Actually there isnt a well known API for checking against catalog indices (unless I missed it the other day). You'd think there'd be a simple catalog.hasColumn('foo') call, but there isnt. Instead you have to do catalog._catalog.schema.has_key('foo').
you're correct, ZCatalog has seen many changes. but instead of giving up and hardcoding an expected environment just a couple more lines of code can go a long way towards ameliorating the impact of those changes.
Sure, we'd all like perfect code but trying to hit a moving target like Zope is hard. Ideally yes everyone would rather write a function that is perfect and ideal, but when you change something in Zopes basic API that has been unchanged for something like 2 years products are going to break, live with it. In the world of product authors producing products in their spare time its hard to get a product out all, never mind trying to maintain it as Zope changes. -- Andy McKay www.agmweb.ca
(unless I missed it the other day). You'd think there'd be a simple catalog.hasColumn('foo') call, but there isnt. Instead you have to do catalog._catalog.schema.has_key('foo').
If this is the only and correct code to check this, why not modifing the API: def hasColumn(self, colName): return self._catalog.schema.has_key(colName) ??? Regards, Dirk
If this is the only and correct code to check this, why not modifing the API:
def hasColumn(self, colName): return self._catalog.schema.has_key(colName)
Actually I think you can also get a list. 'Cos it was late last night and I was fixing a bug, and I still havent figured which cvs branch / tag I'm meant to be on now 2.6 is out :) -- Andy McKay www.agmweb.ca
Zope used to create a bunch of indexes in the Catalog by default. It no longer does so. Squishdot is likely relying on this behavior. A solution is to figure out the indexes that used to be "preinstalled" with a catalog (by downloading and installing 2.5.1) and install them manually in the Squishdot catalog. On Sun, 2002-10-27 at 15:49, viriya wrote:
Hi, I install new Zope-2.6.0 on FreeBSD 4.6.2 and add Squishdot 1.4.1 products with no error message found in control pannel but when I add new squishdot site or zexp from my backup import a message show :
Error Value: list.index(x): x not in list
Site Error Log at /error_log Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.Squishdot, line 49, in manage_addSquishdot Module Products.Squishdot.SquishSite, line 182, in __init__ Module Products.Squishdot.SquishSite, line 155, in _buildIndexing Module Products.ZCatalog.Catalog, line 208, in delColumn ValueError: list.index(x): x not in list
Do you have any suggestion to solve this problem?
Thank,
Viriya
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (7)
-
Andy McKay -
Chris McDonough -
Chris Withers -
Dirk Datzert -
Jens Vagelpohl -
Jerome Alet -
viriya