A recent e-mail from Mr. KinoSearch to java-user has a quote that I
wanted to point out here:
Begin forwarded message:
> KS 0.20 doesn't even have Document or Field classes. :) They've
> been eliminated, and native Perl hashes are now used to transport
> document data.
I think we could simplify (wow, even at this early stage) the solrb
code a bit by simply representing a document as a Hash. For
multiValued data, the values would be arrays. Do we really need any
other semantics at the solrb level, or does a Hash convey it all?
Just thinking out loud here, so feel free to ignore me.
Marvin makes some other great points about fixed schemas, which maps
to the schema.xml facility of Solr I believe. I am interested in
exploring how field names get mapped, along with client knowledge of
Solr's schema.xml structure, can make an elegant API.
Erik
p.s. I've queued up several ruby-dev e-mails to respond to over the
next several days. I'm happily swamped and eager to keep the
momentum of solrb and Flare going strong.
wanted to point out here:
Begin forwarded message:
> KS 0.20 doesn't even have Document or Field classes. :) They've
> been eliminated, and native Perl hashes are now used to transport
> document data.
I think we could simplify (wow, even at this early stage) the solrb
code a bit by simply representing a document as a Hash. For
multiValued data, the values would be arrays. Do we really need any
other semantics at the solrb level, or does a Hash convey it all?
Just thinking out loud here, so feel free to ignore me.
Marvin makes some other great points about fixed schemas, which maps
to the schema.xml facility of Solr I believe. I am interested in
exploring how field names get mapped, along with client knowledge of
Solr's schema.xml structure, can make an elegant API.
Erik
p.s. I've queued up several ruby-dev e-mails to respond to over the
next several days. I'm happily swamped and eager to keep the
momentum of solrb and Flare going strong.