[Zope-dev] feedback wanted on ZCatalog changes...

[Anthony Baxter]

>>> Michel Pelletier wrote
> It sounds pretty cool.  The whole idea of a "query language" is one of
> those open ended issues.  Scott@codeit has come up with some interesting
> stuff and so has Phillip Eby.  I think the query language part should be
> resolved before a UI for it is built.
> 
> So I suggest that we table the issue for a bit WRT anyhting involving
> queries.  I like the idea of your screen and think it should be added as
> feature to the next 'revision' of catalog.

The query page I've added supports only _very_ simple queries. It's actually
mostly useful for browsing the catalog objects to view their metadata. 

The queries can be 'search a single index for a single string' or 'list
uniqueValueFor of an index'. It's not suitable for real use in developing
queries, but is insanely useful for debugging and browsing the catalog.

A proper query language would be nice, yes, but it's a bit beyond this
particular idea - hm, what about if it's just called 'Browse Catalog 
Contents' rather than Query?

> Well, one school of thought says that all indexes should conform to a
> common interface.  Indexes 'sort of' work this way, but text indexes
> have a slightly diff interface and certain operations for various
> indexes may or may make sense (like uniqueValuesFor).

In that case, why doesn't UnTextIndex just support the 
hasUniqueValuesFor() method, and always return 0? I still think there's
a benefit to being able to extract the index type from the instance of
the index - no interface is going to be 100% common. If nothing else, 
being able to look at the management tab for the indexes and seeing what
the types of the various indices are would make it easier to debug the
'oops' mistakes where you set it up wrong.

> What really needs to happen is that this whole index snafu which I so
> briliantly screwed Zope into needs to be fixed.  The index interface
> should be modeled, documented, and made consistent across types of
> index.  The problem with this is that the ideal solution would probably
> not be (or require more work to be) backwards compatable with Confera,
> Squishdot, Catalog and ZTables.  Aie.

didn't you have a model for zcatalog? or was that the one that got eaten
by the modelling software? (bad software no donut)

Anthony