On Fri, Dec 5, 2008 at 12:57 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
> <[EMAIL PROTECTED]> wrote:
>> I tried that and the solution looked so clumsy .
>> I need to commit the to read anything was making things difficult
>
> In a high u
fixed in rev 723554
On Dec 4, 2008, at 6:51 PM, jayson.minard wrote:
Solr 1.4-SNAPSHOT seems to now be requiring:
3) org.apache.commons:commons-io:jar:1.4
which doesn't appear to exist on public repositories.
commons-io:commons-io:1.4 does exist.
If you clear your repository and build
dooh -- my fault. I had one in my local repos, but its non-standard
I'll make the fix in just a sec...
thanks
ryan
On Dec 4, 2008, at 6:51 PM, jayson.minard wrote:
Solr 1.4-SNAPSHOT seems to now be requiring:
3) org.apache.commons:commons-io:jar:1.4
which doesn't appear to exist on p
Solr 1.4-SNAPSHOT seems to now be requiring:
3) org.apache.commons:commons-io:jar:1.4
which doesn't appear to exist on public repositories.
commons-io:commons-io:1.4 does exist.
If you clear your repository and build using it, the build fails.
Before entering a bug, is anyone else seein
On Dec 4, 2008, at 5:55 PM, Chris Hostetter wrote:
: Subject: logging revisited...
I'm starting to think Ryan woke up today and asked himself "what's the
best way to screw with Hoss on his day off when he's only casually
skimming email?"
If I knew you had the day off, I would ask about movi
To a certain extent SLF4j makes this decision a fairly small one, namely
what API do you want to code to inside SOLR and what jars do you want to
ship as a part of the distribution. It doesn't really matter if you pick
commons-logging, log4j or slf4j; all have drop in replacements via SLF4j.
They
[
https://issues.apache.org/jira/browse/SOLR-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653535#action_12653535
]
ryguasu edited comment on SOLR-896 at 12/4/08 3:06 PM:
I don't kn
[
https://issues.apache.org/jira/browse/SOLR-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Harris updated SOLR-896:
--
Attachment: SOLR-896.patch
I don't know if this first stab will be useful to anyone else or not, but it
: Subject: logging revisited...
I'm starting to think Ryan woke up today and asked himself "what's the
best way to screw with Hoss on his day off when he's only casually
skimming email?"
: So, with that in mind I think we should consider using the commons-logging API
: and shipping the .war fi
On 4-Dec-08, at 2:33 PM, Chris Hostetter wrote:
: Being the likely two candidates for winning. My guess is that
: narrowing to the two most popular options first would make #2 the
: winner, while voting on the top 10 (w/o any strategy for winning)
: would make #1 the winner.
limiting to only
Solr Query Parser Plugin for Mark Miller's Qsol Parser
--
Key: SOLR-896
URL: https://issues.apache.org/jira/browse/SOLR-896
Project: Solr
Issue Type: New Feature
Components: searc
: Hoss may lay down the rules on us, but if he doesn't (or if hes in a good mood
For the record: i'm (almost) always i na good mood -- it's just hard to
tell because i spell like an angry unibomber wanna-be and i have a moral
objection to using emoticons so my email based sarcasim is very, very
: right, but what should be the role of committers voting in the second round?
: Is it:
:
: 1. Rank the entries the committers like best
: or
: 2. Rank the entries the committers think best represent the community
: preferences.
:
: My understanding of the purpose of the second round is to inter
: Being the likely two candidates for winning. My guess is that
: narrowing to the two most popular options first would make #2 the
: winner, while voting on the top 10 (w/o any strategy for winning)
: would make #1 the winner.
limiting to only voting for the top 2 seems unrepresentative since m
: All apache_solr_c_red.jpg flavoured logos have a total score of 94.
: That should be taken into account IMHO and we should reduce the number
: of choices for these ones.
To re-iterate a comment I made in SOLR-84 that "wouldn't be fair to the
people who have been submitting ideas and then retra
LOL!
On Dec 4, 2008, at 4:43 PM, Ryan McKinley wrote:
While I'm on a roll tossing stuff out there
Since SOLR-560, solr depends on SLF4j as the logging interface.
However since we also depend on HttpClient we *also* depend on
commons-logging. This is a strange. Our maven artifacts n
While I'm on a roll tossing stuff out there
Since SOLR-560, solr depends on SLF4j as the logging interface.
However since we also depend on HttpClient we *also* depend on commons-
logging. This is a strange. Our maven artifacts now depend on two
logging frameworks!
However the good
So do we want to move forward on this?
IIUC, we all agree it should happen, the issues are just what the
specific names should be.
We have a few components:
1. 'common' code that does not depend on anything (even lucene)
2. 'client' (solrj) code that depends on 'common'
3. 'server' (solr) cod
[
https://issues.apache.org/jira/browse/SOLR-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653484#action_12653484
]
Yonik Seeley commented on SOLR-799:
---
Why not plug in an entirely new chain? That is one of
On Thu, Dec 4, 2008 at 7:34 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> The methodology will very likely determine the outcome here, with
>
> https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
> https://issues.apache.org/jira/secure/attachment/12394268/apache_solr
On Dec 4, 2008, at 1:16 PM, Chris Hostetter wrote:
: 1. Have solr committers vote to accept:
:
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
The process as outlined on the wiki was that the commiters should
have a
ranked prefrence vote, after conside
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653452#action_12653452
]
Shalin Shekhar Mangar commented on SOLR-893:
Thanks for the patch Dan.
{code}
if
[
https://issues.apache.org/jira/browse/SOLR-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-887.
Resolution: Fixed
Committed revision 723410.
Thanks Ahmed!
I didn't want to delay c
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-893:
--
Assignee: Shalin Shekhar Mangar
> Unable to delete documents via SQL and deletedP
On Thu, Dec 4, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> I tried that and the solution looked so clumsy .
> I need to commit the to read anything was making things difficult
In a high update environment, most documents would be exposed to an
open reader with no need
Hi,
I was wondering what the backwards-compatibility rules in Solr are? Is
it the same as in Lucene, i.e. public and protected APIs can only be
changed in a major release (X.Y -> (X+1).0) ?
I'd like to consolidate the function queries in Solr and Lucene and it's
gonna be quite messy if we have
The methodology will very likely determine the outcome here, with
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
https://issues.apache.org/jira/secure/attachment/12394268/apache_solr_c_red.jpg
Being the likely two candidates for winning. My guess is that
narr
[
https://issues.apache.org/jira/browse/SOLR-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653396#action_12653396
]
Cameron Pope commented on SOLR-895:
---
I tried moving both root entities under the same elem
: 1. Have solr committers vote to accept:
:
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
The process as outlined on the wiki was that the commiters should have a
ranked prefrence vote, after considering the point totals from the first
vote. (with the ad
On Wed, Dec 3, 2008 at 3:29 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>>
>> [junit] Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 17.101 sec
>> [junit] Test org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
>> FAILED
>
> Any thoughts on this?
>
> Things are building fine on my
[
https://issues.apache.org/jira/browse/SOLR-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653366#action_12653366
]
Noble Paul commented on SOLR-895:
-
why can't this be achieved using multiple root-entities un
[
https://issues.apache.org/jira/browse/SOLR-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Pope updated SOLR-895:
--
Attachment: import-multiple-documents.patch
This is a patch to DataImporter that causes it to import all
DataImportHandler does not import multiple documents specified in
db-data-config.xml
Key: SOLR-895
URL: https://issues.apache.org/jira/browse/SOLR-895
Project: Solr
I'm with Noble. #1 for me as well for the sake of making a decision
and running with a quality logo sooner rather than later.
ObBiasTransparency: Steve Stedman,the designer of sslogo* submissions,
is a good friend of mine. Awesome dude. He does really nice work.
Erik
On Dec 4, 2
I tried that and the solution looked so clumsy .
I need to commit the to read anything was making things difficult
DB provides me 'immediate' reads .
I am sure performance will be hit anyway.
Is Lucene write much faster than DB (embedded) writes?
http://www.h2database.com/html/performance.html
On
A database, just to store uncommitted documents in case they might be
updated, seems like it will have a pretty major impact on indexing
performance. A lucene-only implementation would seem to be much
lighter on resources.
-Yonik
On Thu, Dec 4, 2008 at 11:32 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL
I prefertaking option #1 and not delaying this any further
On Thu, Dec 4, 2008 at 9:57 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> Hoss may lay down the rules on us, but if he doesn't (or if hes in a good
> mood today), +1 on the runoff vote.
>
> Ryan McKinley wrote:
>>
>> We have discussed with
The solution will be an UpdateRequestProcessor (which itself is
pluggable).I am implementing a JDBC based one. I'll test with H2 and
MySql (and may be Derby)
We will ship the H2 (embedded) jar
On Thu, Dec 4, 2008 at 9:53 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> Again, I would hope that
Hoss may lay down the rules on us, but if he doesn't (or if hes in a
good mood today), +1 on the runoff vote.
Ryan McKinley wrote:
We have discussed with the apache PRC (public relations committee),
and they agree that the top choice in the logo contest should be
disqualified for its similarit
Ryan McKinley wrote:
I see two options:
1. Have solr committers vote to accept:
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
2. Have a 'runoff' poll with the top contenders:
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder
> I see two options:
> 1. Have solr committers vote to accept:
>
> https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
> 2. Have a 'runoff' poll with the top contenders:
> https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
> https:
Again, I would hope that solr builds a storage agnostic solution.
As long as we have a simple interface to load/store documents, it
should be easy to write a JDBC/ehcache/disk/Cassandra/whatever
implementation.
ryan
On Dec 4, 2008, at 10:29 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
Cassan
We have discussed with the apache PRC (public relations committee),
and they agree that the top choice in the logo contest should be
disqualified for its similarity to the solaris logo.
Given the rules agreed upon in http://wiki.apache.org/solr/
LogoContest, the next step is for Solr committ
Cassandra does not meet our requirements.
we do not need that kind of scalability
Moreover its future is uncertain and they are trying to incubate it into Solr
On Thu, Dec 4, 2008 at 8:52 PM, Sami Siren <[EMAIL PROTECTED]> wrote:
> Yet another possibility: http://wiki.apache.org/incubator/Cassan
Yet another possibility: http://wiki.apache.org/incubator/Cassandra
It at least claims to be scalable, no personal experience.
--
Sami Siren
Noble Paul ??? ?? wrote:
Another persistence solution is ehcache with diskstore. It even has replication
I have never used ehcache . So I canno
Right.
- we need a "blocking cache" to avoid more than one thread
attempting to generate, but that can be done outside the SolrCache for
now.
- prob want to expose the statistics collected... (see logging
output of new faceting stuff)
- might want a way to dynamically add caches.. but for now
Distributed Search in combination with fl=score returns inconsistent number of
fields
-
Key: SOLR-894
URL: https://issues.apache.org/jira/browse/SOLR-894
Project: Sol
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653244#action_12653244
]
rosher edited comment on SOLR-893 at 12/4/08 2:23 AM:
--
Thanks Noble
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Rosher updated SOLR-893:
Attachment: SOLR-893.patch
Thanks Paul ... I've made that change ... additionally I've noticed that during
a
Another persistence solution is ehcache with diskstore. It even has replication
I have never used ehcache . So I cannot comment on it
any comments?
--Noble
On Wed, Dec 3, 2008 at 8:50 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 5:52 PM, Grant Ingersoll <[E
50 matches
Mail list logo
