I don't have a strong opinion on the usefulness on faceting on null; would someone have a sensible example of faceting on a "null value" ?
We can fix it but I have the impression it's just about fixing a developer's itch because of it being inconsistent with other components; if it helps with Elasticsearch integration then that makes more sense to me. But why would you fix it by "if (value == null) return;" ? Do you think you can make it work with that? I'd rather actually index the marker token defined by 'indexNullAs'. +1 to collect notes on FieldBridge and Document change wishes. On 23 February 2016 at 18:11, Guillaume Smet <guillaume.s...@gmail.com> wrote: > Hi, > > While looking at HSEARCH-1917 which is an issue with faceting and null > values, I came up with the following observations: > 1/ Faceting doesn't take into account indexNullAs > 2/ Faceting doesn't take into account FieldBridges > > 1/ > > In HSEARCH-1917, Hardy talked about supporting indexNullAs. > > Does it make sense for everyone? > > I don't have a strong opinion about it and if we answer no to 2/ for the > time being, maybe it's better to not support it for now (but I would fix > the faceting on null values anyway). > > 2/ > > FieldBridges are also not supported by faceting. In the case of a > TwoWayFieldBridge, we could consider applying the FieldBridge to the values > before storing them in the facet field. > > One thing that made me think about it is that, currently, with the > Elasticsearch backend, facet values are created from the indexed field so > they take into account the FieldBridge. > > Well, apart if it's a facet which has a name different from the field. Then > the facet values are extracted from the facet values created in the Lucene > document. In this case, the behavior is similar to the Lucene backend > behavior. > > My current opinion is that we should for now fix HSEARCH-1917 by adding a > if (value == null) return; at the top of addFacetDocValues and revisit the > 2 subjects later for 6. > > Anyone against me creating an issue to centralize all the things we need to > fix in FieldBridges/Document building for 6? I would rather create a single > issue for now so that we keep an overview of all we need to fix before > defining exactly what we want to do. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
