[Grok-dev] Re: declaring catalog indexes

[Philipp von Weitershausen]

Martijn Faassen wrote:
> The main drawback to this approach is that all indexes are set up 
> centrally. Of course you can write code to adjust the catalog later (and 
> have no setup_catalog), but are there patterns we can come up with to 
> make the creation of indexes more easy?
> 
> Let's translate the above in another proposal:
> 
> class App(grok.Application):
>     grok.local_utility(IntIds, provides=IIntIds)
>     grok.local_utility(Catalog, provides=ICatalog, name='my_catalog')

Why do you make the catalog a named utility? I've seen you like doing 
that (hurry.query's API always expects a name for the catalog, which 
makes for a bit of a confusing API if the catalog's an unnamed utility).

> class AIndex(grok.FieldIndex):
>    grok.catalog(App, 'my_catalog')
>    grok.attribute('a_attribute', ISomeInterface)

As somebody who knows the AttributeIndex API I would've expected 
something like this:

   class AIndex(grok.FieldIndex):
       grok.catalog(App, 'my_catalog')

       field_name = 'a_attribute'
       field_callable = False
       interface = ISomeInterface

> class BIndex(grok.TextIndex):
>    grok.catalog(App, 'my_catalog')
>    grok.attribute('b_attribute', ISomeInterface)

Somebody who's not entirely familiar with the ZODB and how we do 
indexing using the catalog probably won't think that this is 
straight-forward. It's also a lot of typing and repitition. I do 
understand and appreciate that it's pretty flexible because you can add 
additional indexes quite easily.

To reduce typing, the "grok.catalog(...)" line could be guessed if 
everything is in the same module and there's only one catalog (an 
unnamed utility) in the site.

Still, I wonder how many people (coming from Archetypes or other 
libraries that mangle a bit more information together) would expect to 
set the indexing flag directly in the model or in the schema. While this 
would mangle up things badly, I could think of a more compact spelling: 
write a data schema and then write an "index schema" next to it:

   class IMySchema(Interface):

       a_attribute = schema.Int()
       b_attribute = schema.Datetime()

       def c_method():
           pass

   class MySchemaIndexes(grok.Indexes):
       grok.schema(IMySchema) # this is actually the default

       a_attribute = grok.FieldIndex()
       b_attribute = grok.TextIndex(lexicon)  # additional parameters
       c_method = grok.SetIndex()   # field_callable is automatically
                                    # determined from the schema

What do you think?

> The indexes are grokked automatically and get created in the catalog 
> when 'App' is created using a subscriber. This allows an extension 
> modules to create new indexes in the core. Of course the app would still 
> need to be reinstalled to enable those indexes, but with some clever 
> event registration (IApplicationSetup event?) we might be able to handle 
> that quite nicely as well.

I think after setting up the catalog, we want to send an event 
(CatalogAddedEvent or something like that). Only that way we can ensure 
that indexes are set up *after* the catalog (Zope doesn't guarantee 
ordered execution of event handlers).

> One issue that this approach has is if indexes take other parameters 
> than the three I know about (attribute name, interface, boolean on 
> whether to call attribute or not). How do we pass them in? Does anyone 
> have experience with indexes that can use extra information?

The only indexes I've worked so far were attribute indexes. They take 
the three famous arguments but we could simply set them as attributes on 
the object as outlined above.

The TextIndex from zope.app.catalog.text also takes a lexicon as a 
fourth argument, though that too can be set as an attribute like the others.


-- 
http://worldcookery.com -- Professional Zope documentation and training