"A common way is to make a facet string of categoryId-2_name_imageurl. Then in your UI display the categoryId part of the facet."
I've been thinking about doing something like this for the same purposes. Will having an "extra long" facet string like that have any effect on faceting performace? How about facet sorting with facet.sort=index? In my case, the first part of the facet string would be a 'sortable' value that sorts how I want, not just an id. I use facet.sort=index, but my display labels don't actually sort the way I want, so I'm thinking of making a sort key that does, and storing "sortkey_label" in the actual facet value. But I worry this may have an effect on performance if the string gets really long. But I'm thinking/hoping it won't -- at least for faceting the length of string shoudln't matter, I think, but not sure about for sorting. [Obviously you have to make sure to not accidentally store the same 'id' with differently serialized 'metadata', or you'd wind up with two facet values where you meant to have one]. Is there any reason I couldn't use some non-printing control char as the seperator, instead of just in that example ascii underscore? And then the other thing is, once I have these weird long facet strings with embedded 'metadata', if I actually want to 'fq' on one, I need to pass that whole weird string in the fq, clearly. How do people generally deal with this, using this technique? Just do it, pass the whole string? Use some sort of 'prefix' technique (I guess that would be the * wildcard in the fq)? Use two different solr fields, one for faceting with embedded metadata, and a different one with the same values without embedded metadata for actual 'fq' filtering? Thanks for any tips, Jonathan
