Solr
  1. Solr
  2. SOLR-2141

NullPointerException when using escapeSql function

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.1, 4.0
    • Fix Version/s: 4.1, 6.0
    • Labels:
      None
    • Environment:

      openjdk 1.6.0 b12

      Description

      I have two entities defined, nested in each other..

      <entity name="article" query="select category, subcategory from articles">
      <entity name="other" query="select other from othertable where category='$

      {dataimporter.functions.escapeSql(article.category)}

      '
      AND subcategory='$

      {dataimporter.functions.escapeSql(article.subcategory)}

      '">
      </entity>
      </entity>

      Now, when I run that it bombs on any article where subcategory = '' (it's a NOT NULL column so empty string is there) If i do where subcategory!='' in the article query it works fine (aside from not pulling in all of the articles).

      org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.NullPointerException
      at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:424)
      at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:383)
      at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:242)
      at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:180)
      at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:331)
      at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:389)
      at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:370)
      Caused by: java.lang.NullPointerException
      at org.apache.solr.handler.dataimport.EvaluatorBag$1.evaluate(EvaluatorBag.java:75)
      at org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:216)
      at org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:204)
      at org.apache.solr.handler.dataimport.VariableResolverImpl.resolve(VariableResolverImpl.java:107)
      at org.apache.solr.handler.dataimport.TemplateString.fillTokens(TemplateString.java:81)
      at org.apache.solr.handler.dataimport.TemplateString.replaceTokens(TemplateString.java:75)
      at org.apache.solr.handler.dataimport.VariableResolverImpl.replaceTokens(VariableResolverImpl.java:87)
      at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:71)
      at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:237)
      at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:357)
      ... 6 more

      1. dih-config.xml
        0.4 kB
        Vadim Kirilchuk
      2. dih-file.xml
        0.1 kB
        Vadim Kirilchuk
      3. SOLR-2141.b341f5b.patch
        3 kB
        Dominik Siebel
      4. SOLR-2141.patch
        13 kB
        James Dyer
      5. SOLR-2141.patch
        13 kB
        James Dyer
      6. SOLR-2141.patch
        13 kB
        James Dyer
      7. SOLR-2141.patch
        12 kB
        James Dyer
      8. SOLR-2141.patch
        5 kB
        Dominik Siebel
      9. SOLR-2141.patch
        5 kB
        Dominik Siebel
      10. SOLR-2141-sample.patch
        68 kB
        Koji Sekiguchi
      11. SOLR-2141-test.patch
        1 kB
        Vadim Kirilchuk

        Issue Links

          Activity

          Hide
          Koji Sekiguchi added a comment -

          Edward,

          Maybe I'm missing something, but I couldn't reproduce the problem you mentioned using attached short sample.
          Please modify the attached file and reproduce it to share your problem.

          Show
          Koji Sekiguchi added a comment - Edward, Maybe I'm missing something, but I couldn't reproduce the problem you mentioned using attached short sample. Please modify the attached file and reproduce it to share your problem.
          Hide
          Koji Sekiguchi added a comment -

          Don't hesitate to reopen when you reproduce the problem.

          Show
          Koji Sekiguchi added a comment - Don't hesitate to reopen when you reproduce the problem.
          Hide
          Sandeep Parmar added a comment -

          I am also getting same error.

          Thanks,
          Sand

          Show
          Sandeep Parmar added a comment - I am also getting same error. Thanks, Sand
          Hide
          Vadim Kirilchuk added a comment -

          Hi,

          I am facing this error too and it seems that something is broken in 4.x branch.

          I am attaching two files which can help to reproduce the problem:
          1) dih-config.xml
          contains dih configuration which uses escapeSql function with outer entity parameter
          2) dih-file.xml
          To create outer entity without any db related stuff i need to create it from file.
          Note: YOU MUST CHANGE ABSOLUTE PATH TO THIS FILE IN dih-config.xml to correct one.

          --------------------
          Ok, i can also shay the light on what happens under the hood:

          The problem is in instances of VariableResolverImpl which are created every time anyone calls DocBuilder#getVariableResolver();

          First, it is called to create function namespaces which are cached in DocBuilder instance.

          Then it is created when DocBuilder#doFullDump() is called.

          Then subEntity tries to resolve its 'query' parameter which has escapeSql function, and escapeSql function tries to resolve its param with the first VariableResolver which know nothing about current context and outer entity values.

          However all fails a little bit later, when EvaluatorBag#evaluate() is called:
          List l = parseParams(expression, context.getVariableResolver());
          if (l.size() != 1)

          { throw new DataImportHandlerException(SEVERE, "'escapeSql' must have at least one parameter "); }

          String s = l.get(0).toString();
          return s.replaceAll

          Here parseParams returns list with single VariableWrapper, but wrapper.toString returns null because variable cant be resolved. And finally (ta-dam!) replaceAll method is called on null value.

          P.s.
          don`t be confused with FileDataSource for first entity mixed up with Sql query for second entity. Absense of sql datasource has no effect on this bug.

          Thanks, it would be great if this bug will be fixed ASAP.

          Show
          Vadim Kirilchuk added a comment - Hi, I am facing this error too and it seems that something is broken in 4.x branch. I am attaching two files which can help to reproduce the problem: 1) dih-config.xml contains dih configuration which uses escapeSql function with outer entity parameter 2) dih-file.xml To create outer entity without any db related stuff i need to create it from file. Note: YOU MUST CHANGE ABSOLUTE PATH TO THIS FILE IN dih-config.xml to correct one. -------------------- Ok, i can also shay the light on what happens under the hood: The problem is in instances of VariableResolverImpl which are created every time anyone calls DocBuilder#getVariableResolver(); First, it is called to create function namespaces which are cached in DocBuilder instance. Then it is created when DocBuilder#doFullDump() is called. Then subEntity tries to resolve its 'query' parameter which has escapeSql function, and escapeSql function tries to resolve its param with the first VariableResolver which know nothing about current context and outer entity values. However all fails a little bit later, when EvaluatorBag#evaluate() is called: List l = parseParams(expression, context.getVariableResolver()); if (l.size() != 1) { throw new DataImportHandlerException(SEVERE, "'escapeSql' must have at least one parameter "); } String s = l.get(0).toString(); return s.replaceAll Here parseParams returns list with single VariableWrapper, but wrapper.toString returns null because variable cant be resolved. And finally (ta-dam!) replaceAll method is called on null value. P.s. don`t be confused with FileDataSource for first entity mixed up with Sql query for second entity. Absense of sql datasource has no effect on this bug. Thanks, it would be great if this bug will be fixed ASAP.
          Hide
          Dominik Siebel added a comment - - edited

          I am having the exact same issue since upgrading from 4.0.0 nightly (aprox. November 2011) to 4.0.0 stable (and previously also 4.0.0 BETA).

          I already tried to resolve it with the help of the Solr User's mailinglist:
          http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201210.mbox/%3CCAAh4Jhuv86xbVa6=ZdxshUw3FeRuM+ORg4pDTkqAdGagEFbsDg@mail.gmail.com%3E

          Show
          Dominik Siebel added a comment - - edited I am having the exact same issue since upgrading from 4.0.0 nightly (aprox. November 2011) to 4.0.0 stable (and previously also 4.0.0 BETA). I already tried to resolve it with the help of the Solr User's mailinglist: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201210.mbox/%3CCAAh4Jhuv86xbVa6=ZdxshUw3FeRuM+ORg4pDTkqAdGagEFbsDg@mail.gmail.com%3E
          Hide
          Dominik Siebel added a comment -

          Sadly there's no way for me to reopen this issue like Koji Sekiguchi suggested.
          Maybe Edward Rudd can?

          Show
          Dominik Siebel added a comment - Sadly there's no way for me to reopen this issue like Koji Sekiguchi suggested. Maybe Edward Rudd can?
          Hide
          James Dyer added a comment -

          I re-opened the issue as it sounds like an actual problem.

          Vadim/Sand, can either of you create a failing unit test? This would make it a lot easier to fix. Perhaps you can start with something like TestFileListWithLineEntityProcessor . Also, can you point to an svn revision number when this functionality worked for you? This would help track down what broke it.

          Show
          James Dyer added a comment - I re-opened the issue as it sounds like an actual problem. Vadim/Sand, can either of you create a failing unit test? This would make it a lot easier to fix. Perhaps you can start with something like TestFileListWithLineEntityProcessor . Also, can you point to an svn revision number when this functionality worked for you? This would help track down what broke it.
          Hide
          Dominik Siebel added a comment -

          If it helps:
          I just checked for the nightly build I had in use (with DIH working fine) until I started upgrading to 4.0.0 (beta) a few weeks ago:

          apache-solr-4.0-2011-09-16_08-37-32.war

          with

          apache-solr-dataimporthandler-4.0-2011-09-16_08-37-32.jar
          apache-solr-dataimporthandler-extras-4.0-2011-09-16_08-37-32.jar

          Show
          Dominik Siebel added a comment - If it helps: I just checked for the nightly build I had in use (with DIH working fine) until I started upgrading to 4.0.0 (beta) a few weeks ago: apache-solr-4.0-2011-09-16_08-37-32.war with apache-solr-dataimporthandler-4.0-2011-09-16_08-37-32.jar apache-solr-dataimporthandler-extras-4.0-2011-09-16_08-37-32.jar
          Hide
          James Dyer added a comment -

          We really need a failing unit test for this, or at least simplify the config info Vadim supplied with the bare essentials (and maybe a step-by-step how-to) for reproducing this failure.

          Going through the commits since Sept 2011, there isn't any one that seems like it definitely would have caused this. These 3 seem most suspicious but this is just a guess:

          r1201659 - SOLR-2382, pluggable caches
          r1231367 - SOLR-2542, fix for context variables
          r1332292 - SOLR-3422, refactor configuration load

          Show
          James Dyer added a comment - We really need a failing unit test for this, or at least simplify the config info Vadim supplied with the bare essentials (and maybe a step-by-step how-to) for reproducing this failure. Going through the commits since Sept 2011, there isn't any one that seems like it definitely would have caused this. These 3 seem most suspicious but this is just a guess: r1201659 - SOLR-2382 , pluggable caches r1231367 - SOLR-2542 , fix for context variables r1332292 - SOLR-3422 , refactor configuration load
          Hide
          Vadim Kirilchuk added a comment - - edited

          Hi,

          I am attaching the patch (SOLR-2141-test.patch) to existing test that will help to reproduce the issue. (I`d like someone to write another test instead of modifying existing one)

          If you execute this test you will see already mentioned stacktrace in console output:

          Caused by: java.lang.RuntimeException: org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.NullPointerException
          at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:413)
          at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:326)
          at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:234)
          ... 47 more
          Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.NullPointerException
          at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:556)
          at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:411)
          ... 49 more
          Caused by: java.lang.NullPointerException
          at org.apache.solr.client.solrj.util.ClientUtils.escapeQueryChars(ClientUtils.java:206)
          at org.apache.solr.handler.dataimport.EvaluatorBag$3.evaluate(EvaluatorBag.java:101)
          at org.apache.solr.handler.dataimport.EvaluatorBag$6.get(EvaluatorBag.java:223)
          at org.apache.solr.handler.dataimport.EvaluatorBag$6.get(EvaluatorBag.java:1)
          at org.apache.solr.handler.dataimport.VariableResolverImpl.resolve(VariableResolverImpl.java:113)
          at org.apache.solr.handler.dataimport.TemplateString.fillTokens(TemplateString.java:81)
          at org.apache.solr.handler.dataimport.TemplateString.replaceTokens(TemplateString.java:75)
          at org.apache.solr.handler.dataimport.VariableResolverImpl.replaceTokens(VariableResolverImpl.java:91)
          at org.apache.solr.handler.dataimport.ContextImpl.getResolvedEntityAttribute(ContextImpl.java:81)
          at org.apache.solr.handler.dataimport.LineEntityProcessor.init(LineEntityProcessor.java:84)
          at org.apache.solr.handler.dataimport.EntityProcessorWrapper.init(EntityProcessorWrapper.java:74)
          at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:430)
          at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:511)

          P.s my solr is branch_4x 7da8d768b8b08923b274fcf32ca28edd1a78e8eb

          Show
          Vadim Kirilchuk added a comment - - edited Hi, I am attaching the patch ( SOLR-2141-test.patch ) to existing test that will help to reproduce the issue. (I`d like someone to write another test instead of modifying existing one) If you execute this test you will see already mentioned stacktrace in console output: Caused by: java.lang.RuntimeException: org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.NullPointerException at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:413) at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:326) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:234) ... 47 more Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.NullPointerException at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:556) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:411) ... 49 more Caused by: java.lang.NullPointerException at org.apache.solr.client.solrj.util.ClientUtils.escapeQueryChars(ClientUtils.java:206) at org.apache.solr.handler.dataimport.EvaluatorBag$3.evaluate(EvaluatorBag.java:101) at org.apache.solr.handler.dataimport.EvaluatorBag$6.get(EvaluatorBag.java:223) at org.apache.solr.handler.dataimport.EvaluatorBag$6.get(EvaluatorBag.java:1) at org.apache.solr.handler.dataimport.VariableResolverImpl.resolve(VariableResolverImpl.java:113) at org.apache.solr.handler.dataimport.TemplateString.fillTokens(TemplateString.java:81) at org.apache.solr.handler.dataimport.TemplateString.replaceTokens(TemplateString.java:75) at org.apache.solr.handler.dataimport.VariableResolverImpl.replaceTokens(VariableResolverImpl.java:91) at org.apache.solr.handler.dataimport.ContextImpl.getResolvedEntityAttribute(ContextImpl.java:81) at org.apache.solr.handler.dataimport.LineEntityProcessor.init(LineEntityProcessor.java:84) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.init(EntityProcessorWrapper.java:74) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:430) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:511) P.s my solr is branch_4x 7da8d768b8b08923b274fcf32ca28edd1a78e8eb
          Hide
          Dominik Siebel added a comment - - edited

          I just added the patch SOLR-2141.b341f5b.patch for commit b341f5b (github mirror of branch_4x).
          Might this have caused the error?
          The way I see it the EvaluatorBag looses the current context when used in a nested entity.
          The commit was executed in connection with SOLR-2542 as git log shows:

          b341f5b - SOLR-2542: Fixed DIH Context variables which were broken for all scopes other then SCOPE_ENTITY (10 months ago) <Chris M. Hostetter>

          Show
          Dominik Siebel added a comment - - edited I just added the patch SOLR-2141 .b341f5b.patch for commit b341f5b (github mirror of branch_4x). Might this have caused the error? The way I see it the EvaluatorBag looses the current context when used in a nested entity. The commit was executed in connection with SOLR-2542 as git log shows: b341f5b - SOLR-2542 : Fixed DIH Context variables which were broken for all scopes other then SCOPE_ENTITY (10 months ago) <Chris M. Hostetter>
          Hide
          Dominik Siebel added a comment -

          Hi guys,

          I think I might have found the root of evil:
          SOLR-3262 (removing "threads" from DIH). Problem is that in nested entites the used VariableResolverImpl differs from the one used by the EvaluatorBag (since everytime the getVariableResolver method is called a new one gets created) in the functions namespace (since that one get's initialized in the DocBuilder constructor).
          Anyway: I removed the private functionsNamespace cache property from the docBuilder and moved the call EvaluatorBag.getFunctionsNamespace() into DocBuilder.getVariableResolver(). That fixes all of my problems.

          Vadim Kirilchuk, Sandeep Parmar please find attached patch and let me know if this fixes your errors, too.

          Show
          Dominik Siebel added a comment - Hi guys, I think I might have found the root of evil: SOLR-3262 (removing "threads" from DIH). Problem is that in nested entites the used VariableResolverImpl differs from the one used by the EvaluatorBag (since everytime the getVariableResolver method is called a new one gets created) in the functions namespace (since that one get's initialized in the DocBuilder constructor). Anyway: I removed the private functionsNamespace cache property from the docBuilder and moved the call EvaluatorBag.getFunctionsNamespace() into DocBuilder.getVariableResolver(). That fixes all of my problems. Vadim Kirilchuk , Sandeep Parmar please find attached patch and let me know if this fixes your errors, too.
          Hide
          Dominik Siebel added a comment -

          Patch to fix loading of functions namespace at runtime to use the correct (the newly created) VariableResolverImpl

          Show
          Dominik Siebel added a comment - Patch to fix loading of functions namespace at runtime to use the correct (the newly created) VariableResolverImpl
          Hide
          Dominik Siebel added a comment -
          Show
          Dominik Siebel added a comment - /push Vadim Kirilchuk , Sandeep Parmar , James Dyer
          Hide
          Vadim Kirilchuk added a comment - - edited

          Dominik Siebel sorry, but i am very busy this week. I looked through your patch and i think it will fix my issue, however currently i have no time to check it. Thanks for the patch anyway!

          Show
          Vadim Kirilchuk added a comment - - edited Dominik Siebel sorry, but i am very busy this week. I looked through your patch and i think it will fix my issue, however currently i have no time to check it. Thanks for the patch anyway!
          Hide
          James Dyer added a comment -

          Could you try importing again with the latest revision from Trunk/5.x or branch_4x ? Based on my limited understanding of this problem, I think it might have been solved with SOLR-4086.

          In either case, we probably should write a good unit test for this so that it doesn't break again.

          Show
          James Dyer added a comment - Could you try importing again with the latest revision from Trunk/5.x or branch_4x ? Based on my limited understanding of this problem, I think it might have been solved with SOLR-4086 . In either case, we probably should write a good unit test for this so that it doesn't break again.
          Hide
          Dominik Siebel added a comment -

          James Dyer Thanks, this seems to have fixed my problem. I'm currently doing a full import with a build from branch_4x, no NPEs, yet (at ~10% now).
          Sorry for the (maybe) dumb question, but: is there a gonna be a "stable" bugfix release or tag in the near future (not only for this issue, of course)?

          Show
          Dominik Siebel added a comment - James Dyer Thanks, this seems to have fixed my problem. I'm currently doing a full import with a build from branch_4x, no NPEs, yet (at ~10% now). Sorry for the (maybe) dumb question, but: is there a gonna be a "stable" bugfix release or tag in the near future (not only for this issue, of course)?
          Hide
          Dominik Siebel added a comment -

          James Dyer
          After I finally had some time to check whether the indexed results (after the update) are as I expect them to be I had to find out that the importer did not throw any NPE's now, instead the fields are just missing.
          I have 7 fields defined in my nested entity that use escapeSql. Those are the exact fields that don't get indexed now :-/
          Any other suggestions?

          I will have a look at the changed DIH code, maybe i can figure out where this is coming from.

          Show
          Dominik Siebel added a comment - James Dyer After I finally had some time to check whether the indexed results (after the update) are as I expect them to be I had to find out that the importer did not throw any NPE's now, instead the fields are just missing. I have 7 fields defined in my nested entity that use escapeSql. Those are the exact fields that don't get indexed now :-/ Any other suggestions? I will have a look at the changed DIH code, maybe i can figure out where this is coming from.
          Hide
          Dominik Siebel added a comment -

          Hi James Dyer,
          I just worked through the changes in the DIH. Turns out my fields were null, because I used the 'dih.functions.' namespace since the 'dataimporter.functions.' was marked deprecated before the change. Did you change that back on purpose, because it might cause some confusion (like in my case).

          Show
          Dominik Siebel added a comment - Hi James Dyer , I just worked through the changes in the DIH. Turns out my fields were null, because I used the 'dih.functions.' namespace since the 'dataimporter.functions.' was marked deprecated before the change. Did you change that back on purpose, because it might cause some confusion (like in my case).
          Hide
          James Dyer added a comment -

          Dominik,

          Can you confirm for me that with the current Trunk that the functionality is working so long you use the "dataimporter.functions." namespace?

          Removing support for the "dih.functions." namespace was indeed a mistake. I can fix that too (and its a simple change). But I really want to know for sure if your bigger problem is solved first??

          Show
          James Dyer added a comment - Dominik, Can you confirm for me that with the current Trunk that the functionality is working so long you use the "dataimporter.functions." namespace? Removing support for the "dih.functions." namespace was indeed a mistake. I can fix that too (and its a simple change). But I really want to know for sure if your bigger problem is solved first??
          Hide
          Dominik Siebel added a comment -

          Checked with

          git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1413079 13f79535-47bb-0310-9956-ffa450edef68

          from github trunk.
          Everything seems to be running, at least the fields are present.
          On optimize I get a "SEVERE: null:java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/index/IndexableField;)V" from the SpellChecker component, though. But this might be related to some other issue.

          I could not verify with the whole dataset yet since indexing, commit and optimize (required for spellcheckers) take around 5h. I'll get back to you once the import finished on our staging system.

          Show
          Dominik Siebel added a comment - Checked with git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1413079 13f79535-47bb-0310-9956-ffa450edef68 from github trunk. Everything seems to be running, at least the fields are present. On optimize I get a " SEVERE: null:java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/index/IndexableField;)V " from the SpellChecker component, though. But this might be related to some other issue. I could not verify with the whole dataset yet since indexing, commit and optimize (required for spellcheckers) take around 5h. I'll get back to you once the import finished on our staging system.
          Hide
          James Dyer added a comment -

          I've attached a patch which fixes the functions namespace issue. More importantly, it tests for the problem described here, in SOLR-4047 & SOLR-3842.

          My plan is to commit this tomorrow and if you do not have any more problems, I will close this.

          Show
          James Dyer added a comment - I've attached a patch which fixes the functions namespace issue. More importantly, it tests for the problem described here, in SOLR-4047 & SOLR-3842 . My plan is to commit this tomorrow and if you do not have any more problems, I will close this.
          Hide
          James Dyer added a comment -

          better patch. fixes problem for SOLR-3842 also.

          Show
          James Dyer added a comment - better patch. fixes problem for SOLR-3842 also.
          Hide
          James Dyer added a comment -

          this 3rd patch version contains a test that won't begin to fail on Jan 1

          Show
          James Dyer added a comment - this 3rd patch version contains a test that won't begin to fail on Jan 1
          Hide
          Dominik Siebel added a comment -

          Hi James Dyer,
          Index with the whole dataset looks good. So things seem to be fixed now. Thanks for that!

          Just another dumb question:
          What do I use the patch for? Aren't those the changes that are already in the branch_4x & trunk?

          Show
          Dominik Siebel added a comment - Hi James Dyer , Index with the whole dataset looks good. So things seem to be fixed now. Thanks for that! Just another dumb question: What do I use the patch for? Aren't those the changes that are already in the branch_4x & trunk?
          Hide
          James Dyer added a comment -

          final patch to commit, fixes a locale problem in the unit test.

          Dominik, this patch solves the absence of the dih.functions. namespace, so you can use either "dih." or "dataimport." as before. Also, it solves the related problem on SOLR-3842. Finally it has a pretty good unit test that demonstrates this issue, SOLR-3842 and SOLR-4047 (this last one doesn't appear to actually be broken).

          Show
          James Dyer added a comment - final patch to commit, fixes a locale problem in the unit test. Dominik, this patch solves the absence of the dih.functions. namespace, so you can use either "dih." or "dataimport." as before. Also, it solves the related problem on SOLR-3842 . Finally it has a pretty good unit test that demonstrates this issue, SOLR-3842 and SOLR-4047 (this last one doesn't appear to actually be broken).
          Hide
          James Dyer added a comment -

          committed.

          Trunk: r1414242
          4x: r1414250

          Show
          James Dyer added a comment - committed. Trunk: r1414242 4x: r1414250
          Hide
          Dominik Siebel added a comment -

          Hi, James, sorry I already forgot about that. Thanks for the good work!

          Show
          Dominik Siebel added a comment - Hi, James, sorry I already forgot about that. Thanks for the good work!
          Hide
          Commit Tag Bot added a comment -
          Show
          Commit Tag Bot added a comment - [branch_4x commit] James Dyer http://svn.apache.org/viewvc?view=revision&revision=1414260 SOLR-2141 / SOLR-4047 / SOLR-3842 - remove tabs
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] James Dyer
          http://svn.apache.org/viewvc?view=revision&revision=1414250

          SOLR-2141 / SOLR-4047 / SOLR-3842 - fix problems with VariableResolver, better test coverage

          Show
          Commit Tag Bot added a comment - [branch_4x commit] James Dyer http://svn.apache.org/viewvc?view=revision&revision=1414250 SOLR-2141 / SOLR-4047 / SOLR-3842 - fix problems with VariableResolver, better test coverage

            People

            • Assignee:
              James Dyer
              Reporter:
              Edward Rudd
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development