On Mon, Aug 25, 2008 at 11:25 AM, Noble Paul നോബിള് नोब्ळ्
[EMAIL PROTECTED] wrote:
This is a part of requirement for SOLR-561 . It will be a very nice
feature to have the admin console of the master show details of the
slaves also. To do so The master must know about the slaves. The
slaves
CoreContainer.reload should make core aliases point to reloaded core
Key: SOLR-722
URL: https://issues.apache.org/jira/browse/SOLR-722
Project: Solr
Issue Type: Bug
CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
package private)
---
Key: SOLR-724
URL: https://issues.apache.org/jira/browse/SOLR-724
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625277#action_12625277
]
Shalin Shekhar Mangar commented on SOLR-724:
I think you mean get/set
CoreContainer/CoreDescriptor/SolrCore cleansing
---
Key: SOLR-725
URL: https://issues.apache.org/jira/browse/SOLR-725
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-725:
---
Attachment: solr-725.patch
The patch solves the 3 issues this relates to.
The SolrCore handles its
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625286#action_12625286
]
Noble Paul commented on SOLR-725:
-
I wish to know a few things.
* Is anybody using the alias
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-724:
---
Summary: CoreDescriptor.{get,set}CoreProperties should probably not be
public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625289#action_12625289
]
Noble Paul commented on SOLR-724:
-
bq.I'm just trying to reduce public method exposure.
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625304#action_12625304
]
Henri Biestro commented on SOLR-725:
About being inconsistent, this is what this issue
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625305#action_12625305
]
Henri Biestro commented on SOLR-724:
I'm confused about when the 'what-if' rule can apply
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625309#action_12625309
]
Noble Paul commented on SOLR-725:
-
bq. When you make schema/indexing changes that necessitate
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625317#action_12625317
]
Henri Biestro commented on SOLR-725:
bq. What we do is after we make the necessary
Might be irrelevant but do we have to store this information in the
CoreContainer ?
Couldn't we use core-container (master) core properties (slave) to store
that information ?
These would be filled from the servlet filter (on the master side) in the
core-container properties.
To make them
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625326#action_12625326
]
Noble Paul commented on SOLR-725:
-
bq.What we do is after we make the necessary changes do a
On Mon, Aug 25, 2008 at 4:38 PM, Henrib [EMAIL PROTECTED] wrote:
Might be irrelevant but do we have to store this information in the
CoreContainer ?
I am not much worried about where we store it. CoreContainer just
occurred me as an easy place . The problem we are trying to solve is
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akshay K. Ukey updated SOLR-617:
Attachment: solr-617.patch
This patch adds support for the configuration described in the issue
On Aug 22, 2008, at 6:43 PM, Chris Hostetter wrote:
: Can you double check which ant is geting used and make changes as
appropriate?
Actually, wait a minute nightly.sh is just running ant nightly
which is the same as ant test package ... people who want to run
tests
and package
Noble Paul നോബിള് नोब्ळ् wrote:
I am not much worried about where we store it. CoreContainer just
occurred me as an easy place . The problem we are trying to solve is
non-availability of this information anywhere .
We are in no functional disagreement and I'm merely trying to point an
So, what's our status? It appears everything is closed. Do people
feel comfortable w/ where we are at? There has been a whole flurry of
changes in recent weeks (let's not do that again right before a
release, eh?)
Shall I go forward w/ creating some a release candidate?
-Grant
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625347#action_12625347
]
Henri Biestro commented on SOLR-725:
bq . This does not look like a useful way of using
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625346#action_12625346
]
Henri Biestro commented on SOLR-724:
When a method is public, it also has to be
Given that there are backward compat concerns with
https://issues.apache.org/jira/browse/LUCENE-1142
perhaps we should update Lucene again before a release?
-Yonik
On Mon, Aug 25, 2008 at 9:02 AM, Grant Ingersoll [EMAIL PROTECTED] wrote:
So, what's our status? It appears everything is closed.
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625365#action_12625365
]
Yonik Seeley commented on SOLR-725:
---
bq. According to me the alias feature is implemented
+1 for Lucene upgrade
+1 for a release (I *think* none of the recent SOLR-7** issues have to go in
1.3)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Erik Hatcher [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Monday, August
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625369#action_12625369
]
Shalin Shekhar Mangar commented on SOLR-724:
I feel that CoreContainer and
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625377#action_12625377
]
Henri Biestro commented on SOLR-724:
Obviously different :-)
In my mind, these are
On Aug 25, 2008, at 10:30 AM, Shalin Shekhar Mangar wrote:
+1 for Lucene upgrade
+1 for a release candidate.
I think the newer issues can make it to 1.3.1 easily. We don't need
to halt
1.3 for them.
A general question -- how long does a Release Candidate phase lasts?
In Lucene Java, we
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625390#action_12625390
]
Mark Miller commented on SOLR-724:
--
I agree with Henri.
Having these methods public ties
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-724.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Shalin Shekhar Mangar
On Mon, Aug 25, 2008 at 8:23 PM, Grant Ingersoll [EMAIL PROTECTED]wrote:
In Lucene Java, we typically freeze for 10 days, during which only
blockers and documentation patches are allowed to be committed. I'd be fine
w/ 7, but what's 3 more days, right?
Thanks for the info Grant.
I've
OK, so how about we upgrade Lucene again and then we set a freeze date
for Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm
the one calling it :-) )
-Grant
On Aug 25, 2008, at 11:20 AM, Shalin Shekhar Mangar wrote:
On Mon, Aug 25, 2008 at 8:23 PM, Grant Ingersoll
Grant, if you have time to make the RC today, we could run it until next
weekend and have the 1.3 released on Monday.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin Shekhar Mangar [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
[
https://issues.apache.org/jira/browse/SOLR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic updated SOLR-374:
--
Fix Version/s: 1.4
use IndexReader.reopen
--
Key:
On Mon, Aug 25, 2008 at 8:55 PM, Grant Ingersoll [EMAIL PROTECTED]wrote:
OK, so how about we upgrade Lucene again and then we set a freeze date for
Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one
calling it :-) )
Aren't we going to create a branch for this? If
I was thinking we might want a day or two on the new Lucene and also
that not everyone is reading this thread immediately, so we need to
give them time to react. But, yeah, we can create the branch today,
if that's what people want. Yonik, do you want to do the Lucene
upgrade (you're
Just came across http://wiki.apache.org/solr/IndexPartitioning . Does anyone
think we still need this idea (vs. MultiCore)?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
I'm creating a FacetComponent that is a simple extension of the regular one
(I'm creating numeric ranges for some fields). I would like to preserve most
of the original functionality, and only override the default behavior for
some specific cases. The problem I'm facing is that a lot of the core
+1 for 1.3 RC.
The idea of putting new issues in 1.3.1 has been tossed around a few
times on this list in the last few weeks. I'm not sure how other
people feel about this, but in my mind, 1.X.Y and 1.X.Z releases
should be feature-identical, with later releases only containing
: Because the maven artifacts are part of packaging for release. People who
: don't want them can run create-package, or we could call it core-package. I
The problem i have is that up until now, anyone that wanted to
checkou the source and build it could run ant package and get a nice
zip
: Aren't we going to create a branch for this? If yes, why not upgrade lucene
: jars and freeze right now and release on 1st September? :-)
release branches are created, but durring the days leading up to a release
it's a good idea to refrain from doing too much work on the trunk:
1) it makes
: The idea of putting new issues in 1.3.1 has been tossed around a few times on
: this list in the last few weeks. I'm not sure how other people feel about
: this, but in my mind, 1.X.Y and 1.X.Z releases should be feature-identical,
: with later releases only containing bugfixes. If we have a
: OK, so how about we upgrade Lucene again and then we set a freeze date for
: Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one
: calling it :-) )
Grant, Just to clarify.
you want to:
1) freeze the *trunk* on the 27th
2) focus on bug fixes and documentation
Yonik Seeley wrote:
Given that there are backward compat concerns with
https://issues.apache.org/jira/browse/LUCENE-1142
perhaps we should update Lucene again before a release?
As the maintainer of the Debian solr package, I would be interested to
know whether solr 1.3 will be compatible
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625541#action_12625541
]
Henri Biestro commented on SOLR-725:
Otis, this does not hold releasing 1.3; I'm glad
On Aug 25, 2008, at 1:50 PM, Chris Hostetter wrote:
: Because the maven artifacts are part of packaging for release.
People who
: don't want them can run create-package, or we could call it core-
package. I
The problem i have is that up until now, anyone that wanted to
checkou the
On Aug 25, 2008, at 2:18 PM, Chris Hostetter wrote:
: OK, so how about we upgrade Lucene again and then we set a freeze
date for
: Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm
the one
: calling it :-) )
Grant, Just to clarify.
you want to:
1) freeze the *trunk*
On Mon, 25 Aug 2008 09:34:28 -0700 (PDT)
Otis Gospodnetic [EMAIL PROTECTED] wrote:
Just came across http://wiki.apache.org/solr/IndexPartitioning . Does anyone
think we still need this idea (vs. MultiCore)?
interesting - it sounds to me more like shards than multicore, doesn't it? ...
but
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625631#action_12625631
]
Shalin Shekhar Mangar commented on SOLR-725:
It seems that calling Alias may lead
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635
]
Noble Paul commented on SOLR-725:
-
bq.Paul - I haven't looked at Henri's patch, but like
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635
]
noble.paul edited comment on SOLR-725 at 8/25/08 10:51 PM:
---
bq.Paul
51 matches
Mail list logo
