On 6/29/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> so we should test that use case (ie: containing 1 small
> documents;
For processing a single request with 1 documents, the existing XPP
update handler is faster then the new StaxUpdateHandler.
XPP: 6888 6714
STAX: 8665 8313
Have
On 6/29/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
If I remove logging, the same test runs in:
STAX: 6783 6834
essentially equivalent to the XPP version
What about if you remove the logging for the XPP version too?
-Yonik
so we should test that use case (ie: containing 1 small
documents;
For processing a single request with 1 documents, the existing XPP
update handler is faster then the new StaxUpdateHandler.
XPP: 6888 6714
STAX: 8665 8313
I looked into it, and the difference seems to be entirely
On 6/29/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
How do you all feel about moving:
XmlUpdateRequestHandler -> XppUpdateRequestHandler
StaxUpdateRequestHandler -> XmlUpdateRequestHandler
then deprecating XppUpdateRequestHandler?
+1
I think we could remove the XppUpdateRequestHandler re
I'm kinda out of the looop on the whole Stax/Xpp/Xml update parsing stuff
... am i remembering correctly the end game goal is to reduce/eliminate
dependencies on XPP? (because ? stax is Java "standard"
included out-of-the-box with java6? (i'm guessing))
For me the biggest reason is
: How do you all feel about moving:
: XmlUpdateRequestHandler -> XppUpdateRequestHandler
: StaxUpdateRequestHandler -> XmlUpdateRequestHandler
:
: then deprecating XppUpdateRequestHandler? This will urge people to use
: the Stax implemenation sooner then later and should help iron out any
: p
I just did some performance testing to compare the stax vs xpp
implementaion. As far as I can tell there is no real difference between
them.
Using solrj, this adds 1 documents for each handler - running each
as an independent call.
STAX: 8631 8221 8525 8383 8487 = 42247
XPP: 8309 8438
[
https://issues.apache.org/jira/browse/SOLR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-279.
---
Resolution: Fixed
committed.
> System Properties for Testing are now in Java code AND Ant build.xml
>
Yonik,
Thanks for commit 551701, I have created bug https://
issues.apache.org/jira/browse/SOLR-279 for removing the properties
from build.xml as well.
Cheers,
Eric
---
Principal
OpenSource Connections
Site: http://www.opensourceconnectio
[
https://issues.apache.org/jira/browse/SOLR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-279:
---
Attachment: syspropties.patch
Patch file for build.xml for removing system properties
> System Properties for
System Properties for Testing are now in Java code AND Ant build.xml
Key: SOLR-279
URL: https://issues.apache.org/jira/browse/SOLR-279
Project: Solr
Issue Type: Bug
Aff
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509164
]
Ryan McKinley commented on SOLR-278:
yes, there must a better solution to merge schema vs index field info. I'm
o
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509160
]
Will Johnson commented on SOLR-278:
---
I guess I was hoping for a super set of features in
LukeResponse.FieldInfo which
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509156
]
Ryan McKinley commented on SOLR-278:
looks good. Do you have suggestions on how to modify SOLR-266? The schema
i
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-278:
--
Attachment: LukeSchemaHandling.patch
> LukeRequest/Response for handling show=schema
> --
LukeRequest/Response for handling show=schema
-
Key: SOLR-278
URL: https://issues.apache.org/jira/browse/SOLR-278
Project: Solr
Issue Type: Improvement
Components: clients - java
Affe
16 matches
Mail list logo
