On Sep 16, 2008, at 10:12 AM, Jason Rutherglen wrote:
Hello Ryan,
SQL database such as H2
Mainly to offer joins and be able to perform hierarchical queries.
Also any other types of queries a hybrid SQL search system would
offer. This is something that is best built into SOLR rather than
Lucene. It seems like a lot of the users of SOLR work with SQL
databases as well. It would seem natural to integrate the two. Also
the Summize realtime search system that Twitter purchased worked by
integrating with Mysql. The way to do something similar in Lucene
would be to integrate with a Java SQL database. Also hierarchical
queries could be performed faster using this method (though I could be
wrong, if there is a better way).
Defiantly sounds interesting -- not on my personal TODO list, but I
can see the value and would support this direction (perhaps as a
contrib?)
For starters, it seems like everything could happen in a custom
RequestHandler (perhaps QueryComponent?)
to have multiple lucene indexes within a single SolrCore?
I don't like the whole multi core thing from an administrative
perspective. That means each index needs a separate schema and
configuration etc. That becomes hard to manage if there are 10+
indexes required and is definitely not as simple as an SQL database
does not require so many separate directories and manual
configuration.
I 100% agree that that multicore configuration gets unwieldy quickly.
That said what I'm hearing from you is the config is problematic, not
that you really need multiple lucene indexes in the same SolrCore.
FYI -- the name "SolrCore" is perhaps legacy from when it was static
and had access to the only index available. With "MultiCore" we
removed all the static access and each lucene index gets a SolrCore.
Maybe better to think of SolrCore as SolrIndex -- everythign you can
do with one index.
Yes, I would like to see a way to specify all the fieldtypes /
handlers in one location and then only specify what fields are
available for each core.
So yes -- I agree. In 2.0, I hope to flush out configs so they are
not monstrous.
It would be simple to add this into SOLR. In general
though I have trouble figuring out many of the design decisions of
SOLR though and so hesitate to implement things that seem to go
against the SOLR design model (is there one?).
The 1.X line is organic growth from an internal CNET architecture.
I hope the 2.X line will have more consistent design model...
As far as getting around the exiting multicore configs.... I do this
in my code by overriding:
protected CoreContainer.Initializer createInitializer() {
return new CoreContainer.Initializer();
}
in SolrDispatchFilter.
I actually initialize the CoreContainer manually (pulling some info
from a SQL database)
9. Distributed search and updates using a object serialization which
Where would I start with integrating this into SOLR? Need some help
on that part of it. Tell me what's best and I'll integrate it, it
should be the easiest on the list.
not sure ;) Distributed search is one of the areas I have not looked
at....
ryan
