ically scanning a directory of configuration files.
>>>>> When
>>>>> a new one appears, or an existing file is touched, load it. When a
>>>>> configuration disappears, unload it. This model works very well for
>>>>> servlet
>>>>&
ad it. When a
>>>> configuration disappears, unload it. This model works very well for
>>>> servlet
>>>> containers.
>>>>
>>>> Lance
>>>>
>>>> -Original Message-
>>>> From: [EMAIL PR
ROTECTED]>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> My vote is for dynamically scanning a directory of configuration files.
>>>>> When
>>>>> a new one appears, or an existing file is touched, load it. When a
dnesday, 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 dynamic
g file is touched, load it. When a
>>> configuration disappears, unload it. This model works very well for
>>> servlet
>>> containers.
>>>
>>> Lance
>>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTEC
> 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.
Multi core seems like more of a hack to get around running multiple
JVMs. It doesn't seem like the most elegant solutions for most
problems because usually the s
08 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 a
> 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.
ears, unload 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
> Subj
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 Ja
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 co
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 swap in a new schema object for an index at any
> time...
>
] [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 rewritt
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
> 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 lim
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 filesys
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 quer
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
configu
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, 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
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
Lu
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
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
23 matches
Mail list logo
