On Feb 12, 2008, at 2:10 PM, Chris Hostetter wrote:
: > 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?
How do I generate URLs to retrieve a document against any given Solr
instance that I happen to be pointing at without knowing which field
is the document id? At any rate, the problem is solved in SOLR-478
in less than 10 lines of code and doesn't introduce back-compat.
issues. I invoke this on instantiation of my client, get the field
and then keep it around for use later.
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
+1
