: It would also be nice to move:
: AbstractSolrTestCase.java, TestHarness.java, and o.a.s.util.test to:
: \solr\src\test\org\apache\solr\util
FYI: AbstractSolrTestCase and TestHarness are in the src/java tree instead
of the src/test tree so that they get included in the solr.jar and people
usin
: I agree. I started down that path, and it gets pretty ugly. I
: stopped. I have opted for a syntax that 'updates' all stored fields,
: but lets you say explicitly what to do for each field. If there is a
: stored field you want to skip, you can specify that in command rather
: then in the sc
: For XML, I think trusting the XML parser, and not the servlet
: container is a better way to go.
: That means handing the XML parser an InputStream instead of a Reader.
you mean if there is no charset in the content-type? ... yeah, that was
what i (think i) was suggesting as far as XML goes, tr
On Feb 1, 2007, at 12:31 AM, Chris Hostetter wrote:
: What about putting the tutorial completely on the wiki?
:
: We could pull the wiki page into a distribution to lock it in
: statically.
if we had an easy way to automagically slurp the wiki into every
release
as cross linked HTML i'd be e
On Feb 2, 2007, at 7:50 PM, Mike Klaas wrote:
On 2/2/07, solr-dev@lucene.apache.org
wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2, Failures: 1, Errors: 0, Tim
On Feb 2, 2007, at 9:01 PM, Yonik Seeley wrote:
The whole thing looks long to me. On my local PC, a test only
takes 1:40
No doubt you're running more stuff than me, but get yourself a Mac :)
BUILD FAILED
/Users/erik/dev/solr/build.xml:295: Tests failed!
Total time: 1 minute 5 seco
[
https://issues.apache.org/jira/browse/SOLR-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469938
]
Erik Hatcher commented on SOLR-122:
---
Coda - let's add the libxml2 support like AWS::S3 does:
http://rubyforge.org/vi
On 2/2/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> > Does anyone know how to access the build logs? I don't know from
> > apache infra (except people./minotaur.)
>
> It's on the lucene zone with restricted access.
> It might be possible to set
On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Does anyone know how to access the build logs? I don't know from
> apache infra (except people./minotaur.)
It's on the lucene zone with restricted access.
It might be possible to set something up to copy some stuff to
minotaur on a failure t
On 2/2/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
On 2/2/07, solr-dev@lucene.apache.org wrote:
>
> checkJunitPresence:
>
> compile:
> [mkdir] Created dir: /tmp/apache-solr-nightly/build
> [junit] Running org.apache.solr.update.AutoCommitTest
> [junit] Tests run: 2, Failures: 1, Error
On Feb 2, 2007, at 6:32 PM, Yonik Seeley (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SOLR-138?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12469907 ]
Yonik Seeley commented on SOLR-138:
---
I'm starting to lik
On 2/2/07, solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 26.557 sec
[junit] Test org.apache.
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[javac] Compiling 170 source files to /tmp/apache-solr-nightly/build
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[
[
https://issues.apache.org/jira/browse/SOLR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469907
]
Yonik Seeley commented on SOLR-138:
---
I'm starting to like this idea...
Before, if some queries were taking a long tim
[
https://issues.apache.org/jira/browse/SOLR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469905
]
Yonik Seeley commented on SOLR-138:
---
One method to "fix" this would be to limit the number of queries that may be
ex
queries can stack up
Key: SOLR-138
URL: https://issues.apache.org/jira/browse/SOLR-138
Project: Solr
Issue Type: Bug
Reporter: Yonik Seeley
A burst of "expensive" queries can cause contention within lucene,
[
https://issues.apache.org/jira/browse/SOLR-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469902
]
Yonik Seeley commented on SOLR-130:
---
Perhaps this should be a Wiki page to make it easier to change / collaborate?
>
[
https://issues.apache.org/jira/browse/SOLR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469900
]
Yonik Seeley commented on SOLR-135:
---
Sounds good in general, I think.
The test request handler (in tst), was for lev
>
> How about: Iterable
Maybe... but that might not be the easiest for request handlers to
use... they would then need to spin up a different thread and use a
pull model (provide a new doc on demand) rather than push (call
addDocument()).
With Iterable, you don't need to start a thread to impl
On 2/1/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> Not sure... depends on how update handlers will use it...
by update handler, you mean UpdateRequestHandler(s)? or UpdateHandler?
Both.
> One thing we might not want to get rid of though is streaming
> (constructing and adding a document
On 2/1/07 6:00 PM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote:
> That may be, but Solr was only publicly available for 9 months before we
> had someone running into confusion because they were tyring to post an XML
> file that wasn't UTF-8 :)
>
> http://www.nabble.com/wana-use-CJKAnalyzer-tf
Some standalone tests for charset handling would be nice... something
that we could
use to test the major servlet containers w/ Solr before finalizing a release.
If someone is having problems with international chars, they could
also run the tests against their particular server.
-Yonik
On 2/1/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
...the only real question in my mind is what to do if user supplied data
has *NO* charset information of any kind ... for XML the spec seems very
clear that in that case you test for UTF-8 or UTF-16 ... but for arbitrary
streams of character d
On 2/1/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
I think camelCase is fine since it'd only require one place to be
changed instead of others.
Huh... I knew it was inconsistent, but didn't realize that it was only
a single keyword (fieldtype).
-Yonik
OK, it worked this time.
-Yonik
On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Not sure why this failed. I'm kicking it off again manually.
-Yonik
On 2/1/07, solr-dev@lucene.apache.org wrote:
>
> checkJunitPresence:
>
> compile:
> [mkdir] Created dir: /tmp/apache-solr-nightly/build
Not sure why this failed. I'm kicking it off again manually.
-Yonik
On 2/1/07, solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[javac] Compiling 170 source files to /tmp/apache-solr-nightly/build
[javac] Note: Som
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[javac] Compiling 170 source files to /tmp/apache-solr-nightly/build
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[
They are needed to support the optional attributes of the in the
update XML message:
http://wiki.apache.org/solr/UpdateXmlMessages
allowDups() does not check for uniqueness of the key field.
overwriteBoth() overwrite both pending and committed
I think addConditionally() only adds the document
fieldtype -> fieldType consistency change in schema.xml
---
Key: SOLR-137
URL: https://issues.apache.org/jira/browse/SOLR-137
Project: Solr
Issue Type: Improvement
Components: doc
snappuller - "date -d" and locales don't mix
Key: SOLR-136
URL: https://issues.apache.org/jira/browse/SOLR-136
Project: Solr
Issue Type: Bug
Components: replication
Environment:
[
https://issues.apache.org/jira/browse/SOLR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469732
]
Jürgen Hermann commented on SOLR-93:
If this is your only problem:
/home/hossman/tmp/apache-solr-1.1.0-incubating/e
1) regardless of the verb (updatable/modifiable) i'm not sure that it
makes sense to annotate in the schema the fields that should be copied on
update, and not label the feilds that must be "set" on update (ie: the
fields that cannot be copied)
I agree. I started down that path, and it gets pr
[
https://issues.apache.org/jira/browse/SOLR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469711
]
Ryan McKinley commented on SOLR-135:
A first start for this would be to move:
/solr/src/java/org/apache/solr/util
Restructure / Refactor codebase for shared libraries
Key: SOLR-135
URL: https://issues.apache.org/jira/browse/SOLR-135
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
34 matches
Mail list logo
