If any code calls context.reindexObject(idxs=['...']) with a list of indexes, ftw.solr only updates those fields, but not ones that correspond to catalog metadata.
This is in opposition to the catalog's behavior, which will always update metadata on any context.reindexObject() call.
This becomes a problem when code is relying on the fact that this is the catalog's behavior, and picks a cheap index like getId to accomplish a reindexing of basically just the metadata. This "use a cheap index" trick is used by ftw.bumblebee for example.
It's unfortunate that the catalog behaves this way, and doesn't provide a clean API to control updating of metadata. But because of that, it's a fact that there's plenty of code around that either deliberately abuses that side-effect of reindexObject(), or at least needs it to work properly.
In my opinion, the default out-of-the box behavior in ftw.solr needs to prioritize consistency.
Unfortunately, fixing this behavior in ftw.solr means that we probably will incur quite a performance penalty. Atomic updates would be much less "atomic" than before, because they would always need to include all metadata fields as well (=fields in the Solr schema for which a Plone catalog metadata column exists with the same name).
If any code calls
context.reindexObject(idxs=['...'])with a list of indexes,ftw.solronly updates those fields, but not ones that correspond to catalog metadata.This is in opposition to the catalog's behavior, which will always update metadata on any
context.reindexObject()call.This becomes a problem when code is relying on the fact that this is the catalog's behavior, and picks a cheap index like
getIdto accomplish a reindexing of basically just the metadata. This "use a cheap index" trick is used byftw.bumblebeefor example.It's unfortunate that the catalog behaves this way, and doesn't provide a clean API to control updating of metadata. But because of that, it's a fact that there's plenty of code around that either deliberately abuses that side-effect of
reindexObject(), or at least needs it to work properly.In my opinion, the default out-of-the box behavior in
ftw.solrneeds to prioritize consistency.Unfortunately, fixing this behavior in
ftw.solrmeans that we probably will incur quite a performance penalty. Atomic updates would be much less "atomic" than before, because they would always need to include all metadata fields as well (=fields in the Solr schema for which a Plone catalog metadata column exists with the same name).