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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
