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
