That's actually a big catch in our case. Is it a problem, performancewise, to set the number of shards to a big number, if only one shard is searched at each query?
Not a problem, you get actually great performance: better than a single index assuming they are all used frequently (a non "warmed up" index will not be very responsive as caches invalidate, so the first hit on such an index after some time might be slower, but overall better throughput).
Still, then there is the problem of keeping a mapping from, in this case, string value to integer.
That's easy to solve in your custom sharding implementation, a simple solution could use a properties file listing the project names, a better one could run a query on the database.
I think I'm gonna try dynamic fields instead of sharding, using a class bridge. That seems more robust to me at the moment.
sure, very reasonable. If it doesn't work out, let's discuss alternatives. You're also welcome in changing whatever you need and send patches to be discussed and integrated.