[jira] Commented: (SOLR-82) specify default values in the schema
[ http://issues.apache.org/jira/browse/SOLR-82?page=comments#action_12460099 ] Ryan McKinley commented on SOLR-82: --- looks great. thanks! > specify default values in the schema > > > Key: SOLR-82 > URL: http://issues.apache.org/jira/browse/SOLR-82 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Assigned To: Hoss Man >Priority: Minor > Attachments: defaultValuesPatch.patch, defaultValuesPatch2.patch, > defaultValuesPatch2.patch > > > It would be nice to specify a default value for a given field in the schema. > Chris Hostetter suggested this in: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SOLR-82) specify default values in the schema
[ http://issues.apache.org/jira/browse/SOLR-82?page=all ] Hoss Man reassigned SOLR-82: Assignee: Hoss Man > specify default values in the schema > > > Key: SOLR-82 > URL: http://issues.apache.org/jira/browse/SOLR-82 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Assigned To: Hoss Man >Priority: Minor > Attachments: defaultValuesPatch.patch, defaultValuesPatch2.patch, > defaultValuesPatch2.patch > > > It would be nice to specify a default value for a given field in the schema. > Chris Hostetter suggested this in: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-82) specify default values in the schema
[ http://issues.apache.org/jira/browse/SOLR-82?page=all ] Hoss Man updated SOLR-82: - Attachment: defaultValuesPatch2.patch Ryan: i finally got a chance to look this over in depth (your second version) and I love it! I'm attaching a patch with some minor modifications... 1) fixed a typo in SchemaField.toString 2) cleaned up some indenting oddness in the lines you modified 3) added the name of the field to your log.fine line in IndexSchema 4) added sample usage to the example schema and 1 exampledoc (utf8-example.xml) 5) replaced your new testclass with a single new method in BasicFunctionalityTest which not only tests that the default is there, but also that it can be explicitly set when adding the doc. what do you think? > specify default values in the schema > > > Key: SOLR-82 > URL: http://issues.apache.org/jira/browse/SOLR-82 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Priority: Minor > Attachments: defaultValuesPatch.patch, defaultValuesPatch2.patch, > defaultValuesPatch2.patch > > > It would be nice to specify a default value for a given field in the schema. > Chris Hostetter suggested this in: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Patches in jira
Thorsten: you may want to review some recent discussion about this issue on both solr-dev (specificly the merrits of making branchs vs keeping patches in Jira) and a related discussion on [EMAIL PROTECTED] (which i bring up only because Doug's comments there reflect my own opinions about ... http://www.nabble.com/-RT--working-with-patches-vs.-branches--tf2650655.html#a7396998 http://www.nabble.com/branches-and-flexible-indexing-tf2805284.html#a7837263 "So I'd vote to wait until patch-based development of this becomes awkward before branching. If several committers want to contribute to this patch, and their changes are difficult to integrate, then we should consider a branch." --Doug in the flexible indexing thread. In a nut shell: we haven't really run into any problems or frustrations using Jira and patches, so there's not really a strong motivation to migrate to a different development approach Regarding some of your specific comments... : I noticed many issues in the jira that are patches but never got : committed. In some cases this is just because of time constraints, in others it may because none of hte committers feel confident enough in the patch to take responsibility for it (see the Java Lucene FAQ for a nice comment on this). In other cases (SOLR-53 and SOLR-14 for example) the patch as currently available doesn't work in all cases and would need a motivated community member to do further work on it before it would be safe to commit. : I noticed that we do not have a sandbox (or incubator) directory for new : components that need: : - more documentation : - more testing/feedback : - more community support : - more ... : : Maybe it would be a good idea to add new stuff in our own internal : incubator and as soon we think it is ready to add it to the core. I'm not understanding this idea ... how would you commit a patch that may need to modify a core piece of code into a "contrib" area of our subversion tree? : The benefit over jira is that other people (besides the original author) : can easily submit patches (based on the work of the original patch : author) against our incubator svn. I don't really understand how that might be better (or easier) then having people apply a patch from Jira, making their modifications, and submitting the modified patch back to Jira. Not to mention: we can't competley open Subversion up so that anyone can commit to it -- so we will always need patches in Jira as a way for community members to submit proposed changes. if we tried to commit *every* patch into a a branch, or contrib area of the subversion repository I suspect the committers could find themselves bogged down very easily. -Hoss
[jira] Updated: (SOLR-89) new TokenFilters for whitespace trimming and pattern replacing
[ http://issues.apache.org/jira/browse/SOLR-89?page=all ] Hoss Man updated SOLR-89: - Attachment: pattern-and-trim-filters.patch Patch containing both new Filters, Factories, and test cases. Feedback would be appreciated, but i'm not in a big rush to commit. > new TokenFilters for whitespace trimming and pattern replacing > -- > > Key: SOLR-89 > URL: http://issues.apache.org/jira/browse/SOLR-89 > Project: Solr > Issue Type: New Feature >Reporter: Hoss Man > Assigned To: Hoss Man > Attachments: pattern-and-trim-filters.patch > > > (note: lumping these in a single issue since i did them both at the same time) > More then one person has asekd me recently about how they can configure > strings which: >a) sort case insensitively >B) ignore leading (and trailing although it's not as big of an issue) > whitespace >c ) ignore certain characters anywhere in the string (ie: strip > punctuation) > The first can be solved already using the KeywordTokenizer in conjunction > with the LowerCaseFilter. I've written a TrimFilter and PatternReplaceFilter > to address the later two. (Strictly speaking, TrimFilter isn't needed since > you cna make a pattern thta matches leading or trailing whitespace, but for > people who are only interested in the whitespace issue, i'm sure > String.trim() is more efficient the a regex) > An example of how they can be used... > > sortMissingLast="true" omitNorms="true"> > > > > > > > > > pattern="([^a-z])" replacement="" replace="all" > /> > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-89) new TokenFilters for whitespace trimming and pattern replacing
new TokenFilters for whitespace trimming and pattern replacing -- Key: SOLR-89 URL: http://issues.apache.org/jira/browse/SOLR-89 Project: Solr Issue Type: New Feature Reporter: Hoss Man Assigned To: Hoss Man (note: lumping these in a single issue since i did them both at the same time) More then one person has asekd me recently about how they can configure strings which: a) sort case insensitively B) ignore leading (and trailing although it's not as big of an issue) whitespace c ) ignore certain characters anywhere in the string (ie: strip punctuation) The first can be solved already using the KeywordTokenizer in conjunction with the LowerCaseFilter. I've written a TrimFilter and PatternReplaceFilter to address the later two. (Strictly speaking, TrimFilter isn't needed since you cna make a pattern thta matches leading or trailing whitespace, but for people who are only interested in the whitespace issue, i'm sure String.trim() is more efficient the a regex) An example of how they can be used... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: preferred xml parser
On Wed, 2006-12-20 at 10:18 -0500, Yonik Seeley wrote: > On 12/20/06, Thorsten Scherler > <[EMAIL PROTECTED]> wrote: > > looking at the source code I wonder whether we have a preferred xml > > parser model? > > > > I mean I can find: > > - pull parsing > > - DOM > > - JDOM (at least in some jira patches) > > IMO, DOM & xpath is good for config. xpath is easy, flexible and less > error prone, and we aren't concerned with performance for reading > config. Agree, for the config. > > Pull parsing (StAX) for anything performance critical. > > XPP was used at the start, but I think there is a longer term plan to > go with StAX. > http://www.nabble.com/XPP-license-tf1468633.html#a3977357 > ok > > SAX I have not seen yet and neither StAX. I made some very good > > experience with StAX lately it is fast and easy to use. > > > > Do we plan to recommend one technique (at least for the core)? > > Do we have plans to create an interface for a SolrDocumentFactory? This > > way we could have various underlying implementation returning always the > > same: xml. > > > > I ask because I may look into SOLR-20 and SOLR-30 and would like to use > > StAX as underlying parser. > > +1 for StAX as the default XML parser. > For a general Java client though, I'd try and make it flexible enough > to get at the underlying data stream so someone could use another > parser if they so desire (or different syntaxes such as JSON). I will think of something. I reckon an good defined interface will do and I would provide the default implementation based on StAX. Cheers for the feedback. salu2 > > -Yonik
[jira] Closed: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=all ] Yonik Seeley closed SOLR-88. Resolution: Invalid Yes, this is a lucene index format issue. Older versions of Lucene often can't open indexes created by newer versions. Use luke.jar with the lucene jars from the Solr lib directory. > Solr index cannot be opened with luke anymore > - > > Key: SOLR-88 > URL: http://issues.apache.org/jira/browse/SOLR-88 > Project: Solr > Issue Type: Bug >Reporter: Thorsten Scherler > Attachments: commits.since.11-27.log > > > http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 > "...I notice a very weird problem that I do not understand. I tried to open > the solr index with luke on trunk and it fails with: > java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file > or directory)..." > I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: preferred xml parser
On 12/20/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: looking at the source code I wonder whether we have a preferred xml parser model? I mean I can find: - pull parsing - DOM - JDOM (at least in some jira patches) IMO, DOM & xpath is good for config. xpath is easy, flexible and less error prone, and we aren't concerned with performance for reading config. Pull parsing (StAX) for anything performance critical. XPP was used at the start, but I think there is a longer term plan to go with StAX. http://www.nabble.com/XPP-license-tf1468633.html#a3977357 SAX I have not seen yet and neither StAX. I made some very good experience with StAX lately it is fast and easy to use. Do we plan to recommend one technique (at least for the core)? Do we have plans to create an interface for a SolrDocumentFactory? This way we could have various underlying implementation returning always the same: xml. I ask because I may look into SOLR-20 and SOLR-30 and would like to use StAX as underlying parser. +1 for StAX as the default XML parser. For a general Java client though, I'd try and make it flexible enough to get at the underlying data stream so someone could use another parser if they so desire (or different syntaxes such as JSON). -Yonik
[jira] Commented: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=comments#action_12459937 ] Thorsten Scherler commented on SOLR-88: --- Cheers Erik. That is good to know. > Solr index cannot be opened with luke anymore > - > > Key: SOLR-88 > URL: http://issues.apache.org/jira/browse/SOLR-88 > Project: Solr > Issue Type: Bug >Reporter: Thorsten Scherler > Attachments: commits.since.11-27.log > > > http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 > "...I notice a very weird problem that I do not understand. I tried to open > the solr index with luke on trunk and it fails with: > java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file > or directory)..." > I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: preferred xml parser
StAX is now supported in JSE6, which has just been released. I also found StAX to be very fast and easy to use. Bill On 12/20/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: Hi all, looking at the source code I wonder whether we have a preferred xml parser model? I mean I can find: - pull parsing - DOM - JDOM (at least in some jira patches) SAX I have not seen yet and neither StAX. I made some very good experience with StAX lately it is fast and easy to use. Do we plan to recommend one technique (at least for the core)? Do we have plans to create an interface for a SolrDocumentFactory? This way we could have various underlying implementation returning always the same: xml. I ask because I may look into SOLR-20 and SOLR-30 and would like to use StAX as underlying parser. salu2
[jira] Commented: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=comments#action_12459927 ] Erik Hatcher commented on SOLR-88: -- Luke would very likely work if you used it with the Solr version of Lucene, rather than modifying Solr's schema. lukeall JAR embeds Lucene, but an older version. > Solr index cannot be opened with luke anymore > - > > Key: SOLR-88 > URL: http://issues.apache.org/jira/browse/SOLR-88 > Project: Solr > Issue Type: Bug >Reporter: Thorsten Scherler > Attachments: commits.since.11-27.log > > > http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 > "...I notice a very weird problem that I do not understand. I tried to open > the solr index with luke on trunk and it fails with: > java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file > or directory)..." > I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=comments#action_12459926 ] Thorsten Scherler commented on SOLR-88: --- Removing omitNorms="true" from the schema.xml fixes this issue. > Solr index cannot be opened with luke anymore > - > > Key: SOLR-88 > URL: http://issues.apache.org/jira/browse/SOLR-88 > Project: Solr > Issue Type: Bug >Reporter: Thorsten Scherler > Attachments: commits.since.11-27.log > > > http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 > "...I notice a very weird problem that I do not understand. I tried to open > the solr index with luke on trunk and it fails with: > java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file > or directory)..." > I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=comments#action_12459920 ] Thorsten Scherler commented on SOLR-88: --- I think found the revision: svn up -r487364 . Before this revision I can open the index with luke. After this commit I cannot do it anymore. Seeing the changes it seems that @omitNorms="true" is svn diff -r487340:487364 Index: example/solr/conf/schema.xml === --- example/solr/conf/schema.xml(revision 487340) +++ example/solr/conf/schema.xml(revision 487364) @@ -47,10 +47,10 @@ limits compression (if enabled in the derived fields) to values which exceed a certain size (in characters). --> - + - + - - - - + + + + - - - - + + + + - + - + - - + + > Solr index cannot be opened with luke anymore > - > > Key: SOLR-88 > URL: http://issues.apache.org/jira/browse/SOLR-88 > Project: Solr > Issue Type: Bug >Reporter: Thorsten Scherler > Attachments: commits.since.11-27.log > > > http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 > "...I notice a very weird problem that I do not understand. I tried to open > the solr index with luke on trunk and it fails with: > java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file > or directory)..." > I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-88) Solr index cannot be opened with luke anymore
[ http://issues.apache.org/jira/browse/SOLR-88?page=all ]
Thorsten Scherler updated SOLR-88:
--
Attachment: commits.since.11-27.log
svn log -v -r{2006-11-27}:HEAD . > commits.since.11-27.log
All commits since the last known working version.
> Solr index cannot be opened with luke anymore
> -
>
> Key: SOLR-88
> URL: http://issues.apache.org/jira/browse/SOLR-88
> Project: Solr
> Issue Type: Bug
>Reporter: Thorsten Scherler
> Attachments: commits.since.11-27.log
>
>
> http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2
> "...I notice a very weird problem that I do not understand. I tried to open
> the solr index with luke on trunk and it fails with:
> java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file
> or directory)..."
> I am using lukeall.jar version 0.6.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-88) Solr index cannot be opened with luke anymore
Solr index cannot be opened with luke anymore - Key: SOLR-88 URL: http://issues.apache.org/jira/browse/SOLR-88 Project: Solr Issue Type: Bug Reporter: Thorsten Scherler http://marc.theaimsgroup.com/?l=solr-dev&m=116661341524556&w=2 "...I notice a very weird problem that I do not understand. I tried to open the solr index with luke on trunk and it fails with: java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file or directory)..." I am using lukeall.jar version 0.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Docu - forrest sitemap
On Tue, 2006-12-19 at 10:57 -0800, Chris Hostetter wrote: > : example sitemap in the project. This sitemap is not used in solr at all, > : but contains code that makes forrest fail for 0.8-dev. > > Thanks for tip Thorsten, I removed the file. > Cheers and de nada. salu > > -Hoss >
Solr index cannot be opened with luke anymore
Hi all, I am using luke (http://www.getopt.org/luke/) for inspecting lucene indexes. When I started to investigate solr I downloaded a nightly (solr-2006-11-27.zip). I played around and quickly after, I started to use trunk. I notice a very weird problem that I do not understand. I tried to open the solr index with luke on trunk and it fails with: java.io.FileNotFoundException: $PATH/solr/data/index/_0.f1 (No such file or directory) I then tried with my old nightly from 11-27 and it works like a charm. Since my local trunk has some code from the issue tracker and some other customization I thought it may be problem of this customization. To test I extended the schema from nightly-11-27 with my custom fields, added some documents and opened (without any problem) the index with luke. Meaning it is not my fields/schema that forces luke to fail. Curious I graped today's nightly and run the example. After adding the solr.xml from the sample docs I try to connect with luke again and get the same error. Notice that the exact same file is missing (_0.f1). Stack: java.io.FileNotFoundException: /home/thorsten/src/apache/apache-solr-nightly-incubating/example/solr/data/index/_0.f1 (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.(RandomAccessFile.java:212) at org.apache.lucene.store.FSIndexInput $Descriptor.(FSDirectory.java:393) at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:402) at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:287) at org.apache.lucene.index.SegmentReader.openNorms(SegmentReader.java:500) at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:157) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115) at org.apache.lucene.index.IndexReader $1.doBody(IndexReader.java:147) at org.apache.lucene.store.Lock$With.run(Lock.java:109) at org.apache.lucene.index.IndexReader.open(IndexReader.java:140) at org.apache.lucene.index.IndexReader.open(IndexReader.java:135) at org.getopt.luke.Luke.openIndex(Unknown Source) at org.getopt.luke.Luke.startLuke(Unknown Source) at org.getopt.luke.Luke.main(Unknown Source) /home/thorsten/src/apache/apache-solr-nightly-incubating/example/solr/data/index/_0.f1 (No such file or directory) I cannot explain why this suddenly happens (when it works like a charm with the last month code). I even wrote a small lucene index/segment debugging tool (if somebody is interested I can add it to the issue tracker), but that it is not showing any problems, nor does searching and updating. Before I start to review all commits since 11-27 does somebody has a guess why and which commit may cause this issue. Further should I open an issue in our tracker? TIA for any infos. salu2
Re: [jira] Commented: (SOLR-86) [PATCH] standalone updater cli based on httpClient
On Tue, 2006-12-19 at 21:03 -0800, Otis Gospodnetic (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/SOLR-86?page=comments#action_12459823 ] > > Otis Gospodnetic commented on SOLR-86: > -- > > Are you working on unifying SOLR-20, SOLR-30, and this into once coherent > java client package? I think that would make quite a few people happy. Yeah, I noticed. I actually did not try to work on the unification of both issues, but maybe I find some time (seeing the community demand on this issues) to have a closer look and unify them somehow. Do not hold your breath since I first need to investigate another issue that I have with the solr index and luke. I will report back ASAP. salu2 > > > [PATCH] standalone updater cli based on httpClient > > --- > > > > Key: SOLR-86 > > URL: http://issues.apache.org/jira/browse/SOLR-86 > > Project: Solr > > Issue Type: New Feature > > Components: update > >Reporter: Thorsten Scherler > > Attachments: solr-86.diff, solr-86.diff > > > > > > We need a cross platform replacement for the post.sh. > > The attached code is a direct replacement of the post.sh since it is > > actually doing the same exact thing. > > In the future one can extend the CLI with other feature like auto commit, > > etc.. > > Right now the code assumes that SOLR-85 is applied since we using the > > servlet of this issue to actually do the update. >
Patches in jira
Hi all, I noticed many issues in the jira that are patches but never got committed. There are some problems in keeping patches for longer time in the issue tracker: - diff not valid against trunk anymore - patch grow multiple version and packages which makes it harder to follow - person who submitted the patch is not around anymore and cannot give feedback about her submission - duplicating issues by other patches doing similar things - emerging merging problems between this duplicating issues - ... I noticed that we do not have a sandbox (or incubator) directory for new components that need: - more documentation - more testing/feedback - more community support - more ... Maybe it would be a good idea to add new stuff in our own internal incubator and as soon we think it is ready to add it to the core. The benefit over jira is that other people (besides the original author) can easily submit patches (based on the work of the original patch author) against our incubator svn. wdyt? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
preferred xml parser
Hi all, looking at the source code I wonder whether we have a preferred xml parser model? I mean I can find: - pull parsing - DOM - JDOM (at least in some jira patches) SAX I have not seen yet and neither StAX. I made some very good experience with StAX lately it is fast and easy to use. Do we plan to recommend one technique (at least for the core)? Do we have plans to create an interface for a SolrDocumentFactory? This way we could have various underlying implementation returning always the same: xml. I ask because I may look into SOLR-20 and SOLR-30 and would like to use StAX as underlying parser. salu2
