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 > <[EMAIL PROTECTED]> 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 > > [email protected] > > http://lists.plone.org/mailman/listinfo/product-developers > > > _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
