I defined objectTypes as:
* Share almost everything in the global schema file (e.g. caching,
dynamic fields, field types, etc.)
* Each objectType defined its own set of available fields
This allowed me to easily index completely different types of objects w/
NO way to query across the different types of objects. Each object type
was stored in its own physical index.
What it enabled me to do easily was:
* Translate a table design in the database to an XML document that
only defined the fields and their types for that table
* Provide for multiple tables in one physical XML schema in one
instance of Solr. This gives me a simple way to provide for indexing new
tables in the database w/out needed to do more work with Solr than
restart the instance.
* Run queries against one instance of SOLR for each of the types, e.g.
/solr/select?ot=users&q=email:mbryzek
Running multiple webapps likely accomplishes the same set of goals, with
more flexibility in customizing all of the schema for each type of
object and thus seems like a better solution.
-Mike
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 6:40 PM
To: solr-user@lucene.apache.org
Subject: RE: Interest in Extending SOLR
: One last note: last night, I did spend a bit of time looking into what
: exactly it would mean to add support for object types in SOLR. I
: modified the code base to support the object type tag in the schema,
: providing a working proof of concept (I'm happy to send a sample
schema
: if anybody is interested). The main changes:
: * Modify IndexSchema to keep an object type
: * Provide a factory in SolrCore that returns the correct
: instance of SolrCore based on object type
: * Modify loading of schema to load one copy per object type
I'm confused ... once you made these modifications, did you have a
seperate index per objectType, each with it's own schema? ... the
seperate
SolrCore instances seem to suggest total isolation, so there was no way
to
query across all objectTypes?
-Hoss
