1 Dec
2012
1 Dec
'12
4:33 p.m.
Some more thoughts :
- We could introduce something like a "PropertyFieldResolver" component
role that for a passed BaseProperty determines what field it should be
indexed in. Then in ObjectPropertySolrMetadataExtractor we loop over the
responses and index accordingly.
- Idea : for fields that have a special type (numbers, geohash, etc.),
double index them both as text and their own type. It grows the index
size more than necessary but simplifies querying. This might affect the
document's score too, so not so sure it's a good idea. Any opinions ?
- Do we want dynamic field types declaration ? This would mean
generating solrconfig.xml and maintaining it in sync for the embedded
veresion. Maybe we will need this anyway for translations. If we don't
it means we have to include more types in the default config (for
example geohash type) and we lose in extensibility/modularism.
Jerome.
On 11/28/2012 06:07 PM, Jerome Velociter wrote:
Hello devs,
This mail following a discussion we've had with Eduard on IRC
concerning the indexing of object property values. On the current Solr
implementation as well as on our lucene plugin, all property values
are stored as text/strings. I've expressed the idea that we probably
want to store each object's property in a field that matches the
XClass property field type. For example, store integers in integer
field types, double as doubles, etc.
My personnal use case is to store geo objects (for example long/lat
coordinates), but I think this has value for other types, numbers for
example (it means you can use those numbers as such when querying for
instance).
Now this will increase the complexity of querying since you would have
for example property_text, property_integer, property_double, etc. vs.
just propertvalue. Again, I think this complexity should be hidden by
the "expending API" Paul mentionned in the mail regarding document
translations.
WDYT ?
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs