[Product-Developers] Design advise for collective.alchemyindex

[Roché Compaan]

My motivation for doing this is in the first place is because of the
poor performance and size of indexes in the ZODB. See my post about it
here:
http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/catalog-indexes

Conflict errors in the portal catalog gives me another reason to explore
alternatives.

So, I have hopes that it will at least become a toddler ;-) And if the
ZODB really proves to be the best solution, then great, but we need
something to compare it with.

I would still love to see your benchmarks.

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za

On Fri, 2008-10-03 at 18:55 +0200, Andreas Jung wrote:
> Are you sure that such an implementation will not be a stillborn child.
> During the TXNG3 implementation I did a lot of benchmarks with alternative 
> storage/lexicon implemenations for TXNG3. All implementations using a RDBMS 
> where more than a magnitude slower than the lamest ZODB implementation. 
> Using an ORM will introduce even more overhead.
> 
> Andreas
> 
> --On 3. Oktober 2008 18:51:06 +0200 Roché Compaan 
> <roche at upfrontsystems.co.za> wrote:
> 
> > I'm wrapping up collective.alchemyindex and want to make the database
> > configuration as flexible enough for developers that want to use or
> > extend it.
> >
> > When indexing an object you have attributes that are single and
> > multivalued. The single valued attributes can be stored in a single
> > table and multivalued attributes need a table per attribute due to the
> > fact that most databases don't have a column type that is multivalued.
> >
> > When indexing an object, one could query for utilities that implement
> > IObjectMapper (or IRecordMapper) to index single valued attributes on a
> > object and query for IKeywordMapper to index attributes that are
> > multivalued.
> >
> > Utilities are really convenient here and it saves me the effort of
> > building a specialised registry for mappers but I'm not sure that the
> > above use case fits the semantics of a utility. But maybe it does?
> >
> > --
> > Roché Compaan
> > Upfront Systems                   http://www.upfrontsystems.co.za
> >
> >
> > _______________________________________________
> > Product-Developers mailing list
> > Product-Developers at lists.plone.org
> > http://lists.plone.org/mailman/listinfo/product-developers
> 
> 
>