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
[
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
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653244#action_12653244
]
rosher edited comment on SOLR-893 at 12/4/08 2:23 AM:
--
Thanks Noble
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:
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
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
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:
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
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:
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
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
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
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
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 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
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:
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,
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
[
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
[
https://issues.apache.org/jira/browse/SOLR-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653366#action_12653366
]
Noble Paul commented on SOLR-895:
-
why can't this be achieved using multiple root-entities
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 local system
: 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
[
https://issues.apache.org/jira/browse/SOLR-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653396#action_12653396
]
Cameron Pope commented on SOLR-895:
---
I tried moving both root entities under the same
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
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
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 to
[
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
[
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
[
https://issues.apache.org/jira/browse/SOLR-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653452#action_12653452
]
Shalin Shekhar Mangar commented on SOLR-893:
Thanks for the patch Dan.
{code}
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
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/browse/SOLR-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653484#action_12653484
]
Yonik Seeley commented on SOLR-799:
---
Why not plug in an entirely new chain? That is one of
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)
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
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
: 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
: 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
: 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
: 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,
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:
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
: 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
[
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
[
https://issues.apache.org/jira/browse/SOLR-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653535#action_12653535
]
ryguasu edited comment on SOLR-896 at 12/4/08 3:06 PM:
I don't
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
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
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
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
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
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 update
50 matches
Mail list logo
