On 1/21/2016 2:22 AM, Prateek Jain J wrote:
> Thanks Erick,
>
> Yes, I took same approach as suggested by you. The issue is some developers
> started with schemaless configuration and now they have started liking it and
> avoiding restrictions (including increased time to deploy application, in
> managed enterprise environment). I was more concerned about pushing best
> practices around this in team, because allowing anyone to new attributes will
> become overhead in terms of management, security and maintainability.
> Regarding your concern about not storing documents on separate disk; we are
> storing them in solr but not as backup copies. One doubt still remains in
> mind w.r.t auto-detection of types in solr:
>
> Is there a performance benefit of using defined types (schema based) vs
> un-defined types while adding documents? Does "solrj" ships this
> meta-information like type of attributes to solr, because code looks
> something like?
>
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("category", "book"); // String
> doc.addField("id", 1234); //Long
> doc.addField("name", "Trying solrj"); //String
>
> In my opinion, any auto-detector code will have some overhead vs the other;
> any thoughts around this?
Although the true reality may be more complex, you should consider that
everything Solr receives from SolrJ will be text -- as if you had sent
the JSON or XML indexing format manually, which has no type information.
When you are building a document with SolrInputDocument, SolrJ has no
knowledge of the schema in Solr. It doesn't know whether the target
field is numeric, string, date, or something else.
Using different object types for input to SolrJ just gives you general
Java benefits -- things like detecting certain programming errors at
compile time.
Thanks,
Shawn
