28 Nov
2012
28 Nov
'12
9:24 p.m.
Jérôme,
you definitely have my +1.
And that's yet another feature of an automated schema generation.
One big plus of this is that indexing can optimize on these types for storage and
retrieval.
I'm fearing, however, that it adds to the work of solr implementation.
I do not understand why you would have property_text and property_integer... why not have
latitude, and latitude is a float?
I think you are aiming more and more at a flexible query expansion routine, correct?
(one that flexibly accepts field values depending on type and that expands across
languages for multilang queriers?). This goes along making the query expansion a default
first-class citizen and go away of the limited "a single string for a query".
paul
Le 28 nov. 2012 à 18:07, Jerome Velociter a écrit :
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