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