: > Honestly: i can't think of a single use case where client code would care
: > about what the uniqueKey field is, unless it already *knew* what the
: > uniqueKey field is.
:
: :-) Abstractions allow one to use different implementations. My
: client/display doesn't know about Solr, it just knows it can search and the
: Solr implementation part of it can be pointed at any Solr instance (or other
: search engines as well), thus it needs to be able to "reflect" on Solr. The
: unique key is a pretty generally useful thing across implementations.
but why does your client/display care which field is the uniqueKey field?
knowing which fields it might query or ask for in the fl list sure -- but
why need to know about hte uniqueKey field specificly?
I could have an index of people where i document thatthe SSN field is
unique, and never even tell you that it's not the 'uniqueKey' Field --
that could be some completley unrelated field i don't want you to know
about called "customerId" -- but that doesn't acceft you as a client, you
can still query on whatever you wnat, get back whatever docs you want,
etc... the onlything you can't do is "delete by id" (since you can't be
sure which field is the uniqueKey) but you can always delete by query.
: In fact, I wish all the ReqHandlers had an introspection option, where one
: could see what params are supported as well.
you and me both -- but the introspection shouldn't be intrinsic to the
ReuestHandler - as the Solr admin i may not want to expose all of those
options to my clients...
http://wiki.apache.org/solr/MakeSolrMoreSelfService
-Hoss
