, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would like
to see the ability to dynamically update the configuration
: Wednesday, September 17, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would like
to see the ability to dynamically update
Hi Yonik,
One approach I have been working on that I will integrate into SOLR is
the ability to use serialized objects for the analyzers so that the
schema can be defined on the client side if need be. The analyzer
classes will be dynamically loaded. Or there is no need for a schema
and plain
it. This model works very well for servlet
containers.
Lance
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley
Sent: Wednesday, September 17, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008
That would allow a single request to see a stable view of the
schema, while preventing having to make every aspect of the schema
thread-safe.
Yes that is the best approach.
Nothing will stop one from using java serialization for config
persistence,
Persistence should not be serialized.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik
Seeley
Sent: Wednesday, September 17, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote
:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would like
to see the ability to dynamically update the configuration and schema
Of Yonik
Seeley
Sent: Wednesday, September 17, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would like
to see
On Tue, Sep 16, 2008 at 10:12 AM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
SQL database such as H2
Mainly to offer joins and be able to perform hierarchical queries.
Can you define or give an example of what you mean by hierarchical queries?
A downside of any type of cross-document queries
If the configuration code is going to be rewritten then I would like
to see the ability to dynamically update the configuration and schema
without needing to reboot the server. Also I would like the
configuration classes to just contain data and not have so many
methods that operate on the
Can you define or give an example of what you mean by hierarchical queries?
Good question, I think Erik Hatcher had more ideas on that. I was
imagining joins or sub queries like SQL does. Clearly they won't be
efficient, but it's easier than implementing joins (or is it) in SOLR?
Joins limit
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would like
to see the ability to dynamically update the configuration and schema
without needing to reboot the server.
Exactly. Actually, multi-core allows you
] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley
Sent: Wednesday, September 17, 2008 11:21 AM
To: solr-user@lucene.apache.org
Subject: Re: Some new SOLR features
On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen
[EMAIL PROTECTED] wrote:
If the configuration code is going to be rewritten then I would
On Wed, Sep 17, 2008 at 4:50 PM, Henrib [EMAIL PROTECTED] wrote:
Yonik Seeley wrote:
...multi-core allows you to instantiate a completely
new core and swap it for the old one, but it's a bit of a heavyweight
approach
...a schema object would not be mutable, but
that one could easily
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
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
ryantxu wrote:
...
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.
...
What about
ryantxu wrote:
...
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.
...
What about using include so each
ryantxu wrote:
Yes, include would get us some of the way there, but not far enough
(IMHO). The problem is that (as written) you still need to have all
the configs spattered about various directories.
I does not allow us to go *all* the way but it does allow to put
Here are my gut reactions to this list... in general, most of this
comes down to sounds great, if someone did the work I'm all for it!
Also, no need to post to solr-user AND solr-dev, probably better to
think of solr-user as a superset of solr-dev.
1. Machine learning based suggest
20 matches
Mail list logo
