Solr
  1. Solr
  2. SOLR-1729

Date Facet now override time parameter

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 3.6, 4.0-ALPHA
    • Component/s: search
    • Labels:
      None
    • Environment:

      Solr 1.4

      Description

      This PATCH introduces a new query parameter that tells a (typically, but not necessarily) remote server what time to use as 'NOW' when calculating date facets for a query (and, for the moment, date facets only) - overriding the default behaviour of using the local server's current time.

      This gets 'round a problem whereby an explicit time range is specified in a query (e.g. timestamp:[then0 TO then1]), and date facets are required for the given time range (in fact, any explicit time range).
      Because DateMathParser performs all its calculations from 'NOW', remote callers have to work out how long ago 'then0' and 'then1' are from 'now', and use the relative-to-now values in the facet.date.xxx parameters. If a remote server has a different opinion of NOW compared to the caller, the results will be skewed (e.g. they are in a different time-zone, not time-synced etc.).
      This becomes particularly salient when performing distributed date faceting (see SOLR-1709), where multiple shards may all be running with different times, and the faceting needs to be aligned.

      The new parameter is called 'facet.date.now', and takes as a parameter a (stringified) long that is the number of milliseconds from the epoch (1 Jan 1970 00:00) - i.e. the returned value from a System.currentTimeMillis() call. This was chosen over a formatted date to delineate it from a 'searchable' time and to avoid superfluous date parsing. This makes the value generally a programatically-set value, but as that is where the use-case is for this type of parameter, this should be ok.

      NOTE: This parameter affects date facet timing only. If there are other areas of a query that rely on 'NOW', these will not interpret this value. This is a broader issue about setting a 'query-global' NOW that all parts of query analysis can share.

      Source files affected:
      FacetParams.java (holds the new constant FACET_DATE_NOW)
      SimpleFacets.java getFacetDateCounts() NOW parameter modified

      This PATCH is mildly related to SOLR-1709 (Distributed Date Faceting), but as it's a general change for date faceting, it was deemed deserving of its own patch. I will be updating SOLR-1709 in due course to include the use of this new parameter, after some rfc acceptance.

      A possible enhancement to this is to detect facet.date fields, look for and match these fields in queries (if they exist), and potentially determine automatically the required time skew, if any. There are a whole host of reasons why this could be problematic to implement, so an explicit facet.date.now parameter is the safest route.

      1. FacetParams.java
        8 kB
        Peter Sturge
      2. SimpleFacets.java
        26 kB
        Peter Sturge
      3. solr-1.4.0-solr-1729.patch
        6 kB
        Thomas Hammerl
      4. SOLR-1729_3x.patch
        47 kB
        Simon Willnauer
      5. SOLR-1729_3x.patch
        46 kB
        Simon Willnauer
      6. SOLR-1729.patch
        24 kB
        Yonik Seeley
      7. SOLR-1729.patch
        21 kB
        Yonik Seeley
      8. SOLR-1729.patch
        13 kB
        Yonik Seeley
      9. UnInvertedField.java
        38 kB
        Peter Sturge

        Issue Links

          Activity

          Hide
          Peter Sturge added a comment -

          These are the source files affected for this patch.
          Apologies for not creating a PATCH file - my tortoise svn is not working for creating patch files.
          If anyone would like to create a patch from these, that would be extraordinarily kind of you!

          Diff: (trunk: 1.4 Release)
          FacetParams.java:
          Add at line 179:
          /**

          • String that tells the date facet counter what time to use as 'now'.
          • The value of this parameter, if it exists, must be a stringified long
          • of the number of milliseconds since the epoch (milliseconds since 1 Jan 1970 00:00).
          • System.currentTimeMillis() provides this.
          • The DateField and DateMathParser work out their times relative to 'now'.
          • By default, 'now' is the local machine's System.currentTimeMillis().
          • This parameter overrides the local value to use a different time.
          • This is very useful for remote server queries where the times on the querying
          • machine are skewed/different than that of the date faceting machine.
          • This is a date.facet global query parameter (i.e. not per field)
          • @see DateMathParser
          • @see DateField
            */
            public static final String FACET_DATE_NOW = "facet.date.now";

          SimpleFacets.java:
          Change at line 551:

          • final Date NOW = new Date();
            + final Date NOW = new Date(params.get(FacetParams.FACET_DATE_NOW) != null ? Long.parseLong(params.get("facet.date.now")) : System.currentTimeMillis());
          Show
          Peter Sturge added a comment - These are the source files affected for this patch. Apologies for not creating a PATCH file - my tortoise svn is not working for creating patch files. If anyone would like to create a patch from these, that would be extraordinarily kind of you! Diff: (trunk: 1.4 Release) FacetParams.java: Add at line 179: /** String that tells the date facet counter what time to use as 'now'. The value of this parameter, if it exists, must be a stringified long of the number of milliseconds since the epoch (milliseconds since 1 Jan 1970 00:00). System.currentTimeMillis() provides this. The DateField and DateMathParser work out their times relative to 'now'. By default, 'now' is the local machine's System.currentTimeMillis(). This parameter overrides the local value to use a different time. This is very useful for remote server queries where the times on the querying machine are skewed/different than that of the date faceting machine. This is a date.facet global query parameter (i.e. not per field) @see DateMathParser @see DateField */ public static final String FACET_DATE_NOW = "facet.date.now"; SimpleFacets.java: Change at line 551: final Date NOW = new Date(); + final Date NOW = new Date(params.get(FacetParams.FACET_DATE_NOW) != null ? Long.parseLong(params.get("facet.date.now")) : System.currentTimeMillis());
          Hide
          Lance Norskog added a comment -

          This is a wider-ranging problem than just date facets. If I am indexing data to several cores I might want to override the NOW tiime for each core. Or a distributed search that uses (NOW/HOUR). And then there's logging.

          Show
          Lance Norskog added a comment - This is a wider-ranging problem than just date facets. If I am indexing data to several cores I might want to override the NOW tiime for each core. Or a distributed search that uses (NOW/HOUR). And then there's logging.
          Hide
          Peter Sturge added a comment -

          I agree there are wider issues that relate to this – this particular patch addresses the time sync issue for allowing distributed date facets to happen.
          In this case, you must have multiple cores using the same NOW for all, so that your date facets are consistent. In fact, it doesn't really matter which now you use, as long they're all the same – the caller setting the now value makes the most sense.

          For other time-related queries, this might not be the case, but as you rightly pointed out, these are not addressed here.

          Show
          Peter Sturge added a comment - I agree there are wider issues that relate to this – this particular patch addresses the time sync issue for allowing distributed date facets to happen. In this case, you must have multiple cores using the same NOW for all, so that your date facets are consistent. In fact, it doesn't really matter which now you use, as long they're all the same – the caller setting the now value makes the most sense. For other time-related queries, this might not be the case, but as you rightly pointed out, these are not addressed here.
          Hide
          Hoss Man added a comment -

          (e.g. they are in a different time-zone, not time-synced etc.).

          time-zones should be irrelevant since all calculations are done in UTC ... lack of time-sync is a legitimate concern, but the more serious problem is distributed requests and network lag. Even if all of the boxes have synchronized clocks, they might not all get queried at the exact same time, and multiple requets might be made to a single server for different phrases of the distributed request that expect to get the same answers.

          It should be noted that while adding support to date faceting for this type of "when is now?" is certainly necessary to make distributed date faceting work sanely, it is not sufficient ... unless filter queries that use date math also respect it the counts returned from date faceting will still potentially be non-sensical.

          Show
          Hoss Man added a comment - (e.g. they are in a different time-zone, not time-synced etc.). time-zones should be irrelevant since all calculations are done in UTC ... lack of time-sync is a legitimate concern, but the more serious problem is distributed requests and network lag. Even if all of the boxes have synchronized clocks, they might not all get queried at the exact same time, and multiple requets might be made to a single server for different phrases of the distributed request that expect to get the same answers. It should be noted that while adding support to date faceting for this type of "when is now?" is certainly necessary to make distributed date faceting work sanely, it is not sufficient ... unless filter queries that use date math also respect it the counts returned from date faceting will still potentially be non-sensical.
          Hide
          Peter Sturge added a comment -

          ...they might not all get queried at the exact same time

          I suppose this is what the explicit 'NOW' is meant to resolve - staggered/lagged receipt/response, and, in an erzatz fashion, discrepencies in local time sync. Since the passed-in 'NOW' is relative only to the epoch, network latency is handled, and time-sync on any given server is assumed to be correct.

          ...multiple requets might be made to a single server for different phrases of the distributed request that expect to get the same answers.

          As long as the same code path is followed for such requests, it should honour the same (passed-in) 'NOW'. Are there scenarios where this is not the case? In which case, yes, these would need to be addressed.

          ...unless filter queries that use date math also respect it the counts returned from date faceting will still potentially be non-sensical.

          Definitely filter queries will need to get/use/honour the same 'NOW' as its corresponding query, otherwise anarchy will quickly ensue.
          Can you point me toward the class(es) where filter queries' date math lives, and I'll have a look? As filter queries are cached separately, can you think of any potential caching issues relating to filter queries?

          Show
          Peter Sturge added a comment - ...they might not all get queried at the exact same time I suppose this is what the explicit 'NOW' is meant to resolve - staggered/lagged receipt/response, and, in an erzatz fashion, discrepencies in local time sync. Since the passed-in 'NOW' is relative only to the epoch, network latency is handled, and time-sync on any given server is assumed to be correct. ...multiple requets might be made to a single server for different phrases of the distributed request that expect to get the same answers. As long as the same code path is followed for such requests, it should honour the same (passed-in) 'NOW'. Are there scenarios where this is not the case? In which case, yes, these would need to be addressed. ...unless filter queries that use date math also respect it the counts returned from date faceting will still potentially be non-sensical. Definitely filter queries will need to get/use/honour the same 'NOW' as its corresponding query, otherwise anarchy will quickly ensue. Can you point me toward the class(es) where filter queries' date math lives, and I'll have a look? As filter queries are cached separately, can you think of any potential caching issues relating to filter queries?
          Hide
          Hoss Man added a comment -

          Peter: I think you may have misconstrued my comments – they were not criticisms of your patch, they were a clarification of why the functionality you are proposing is important.

          Can you point me toward the class(es) where filter queries' date math lives

          it's all handled internally by DateField, at which point it has no notion of the request – I believe this is why yonik suggested using a ThreadLocal variable to track a consistent "NOW" that any method anywhere in Solr could use (if set) for the current request ... then we just need something like SolrCore to set it on each request (or accept it as a parm if specified)

          As filter queries are cached separately, can you think of any potential caching issues relating to filter queries?

          The cache keys for things like that are the Query objects themselves, and at that point the DateMath strings (including "NOW") have already been resolved into realy time values so that shouldn't be an issue.

          Show
          Hoss Man added a comment - Peter: I think you may have misconstrued my comments – they were not criticisms of your patch, they were a clarification of why the functionality you are proposing is important. Can you point me toward the class(es) where filter queries' date math lives it's all handled internally by DateField, at which point it has no notion of the request – I believe this is why yonik suggested using a ThreadLocal variable to track a consistent "NOW" that any method anywhere in Solr could use (if set) for the current request ... then we just need something like SolrCore to set it on each request (or accept it as a parm if specified) As filter queries are cached separately, can you think of any potential caching issues relating to filter queries? The cache keys for things like that are the Query objects themselves, and at that point the DateMath strings (including "NOW") have already been resolved into realy time values so that shouldn't be an issue.
          Hide
          Peter Sturge added a comment -

          Hi Chris,
          Thanks for your comments - I hope I didn't sound like your comments were taken wrongly - I absolutely count on comments from you and other experts to make sure I'm not missing some important functionality and/or side effect. You know the code base far better than I, so its great that you take the time to point out all the different bits and peices that need addressing.

          I can certainly understand the need to address the 'core-global' isssues raised by you and Yonik for storing a ThreadLocal 'query-global' 'NOW'.
          I suppose the main issue in implementing the thread-local route is that we'd have to make sure we found every place in the query core that references now, and point those references to the new variable? If the 'code-at-large' [hopefully] always calls the date math routines for finding 'NOW', great, it should be relatively straightforward. If there are any stray e.g. System.currentTimeMillis(), then it's a bit more fiddly, but still do-able.

          it's all handled internally by DateField
          Sounds like DateField would the best candidate for holding the ThreadLocal? The query handler code can set the variable of its DateField instance if it's set in a query parameter, otherwise it just defaults to it's own local (UTC) time.
          Could be done similarly to DateField.ThreadLocalDateFormat, perhaps?

          Show
          Peter Sturge added a comment - Hi Chris, Thanks for your comments - I hope I didn't sound like your comments were taken wrongly - I absolutely count on comments from you and other experts to make sure I'm not missing some important functionality and/or side effect. You know the code base far better than I, so its great that you take the time to point out all the different bits and peices that need addressing. I can certainly understand the need to address the 'core-global' isssues raised by you and Yonik for storing a ThreadLocal 'query-global' 'NOW'. I suppose the main issue in implementing the thread-local route is that we'd have to make sure we found every place in the query core that references now, and point those references to the new variable? If the 'code-at-large' [hopefully] always calls the date math routines for finding 'NOW', great, it should be relatively straightforward. If there are any stray e.g. System.currentTimeMillis(), then it's a bit more fiddly, but still do-able. it's all handled internally by DateField Sounds like DateField would the best candidate for holding the ThreadLocal? The query handler code can set the variable of its DateField instance if it's set in a query parameter, otherwise it just defaults to it's own local (UTC) time. Could be done similarly to DateField.ThreadLocalDateFormat, perhaps?
          Hide
          Yonik Seeley added a comment -

          Sounds like DateField would the best candidate for holding the ThreadLocal?

          It might be nice to provide a public static method like
          public static long getNow()
          for code that needs the value of NOW w/o going through date math (the ms() function for one)

          The other question is how the value is set to a particular value passed in on the request (for distributed search sync say).
          It seems a bit awkward to have something global like SolrCore.execute checking and setting "NOW"...
          an alternative that could help solve other problems is to have SolrCore.execute set a ThreadLocal<SolrRequest> that things like getNow() could check for a NOW param if it's thread local was not yet set.

          Another thing to think about: unlike the DateFormatter threadLocal, a NOW threadLocal changes behavior - so it needs to be well defined, and not just a local cache no one else knows about. Example: say that we parallelize some things in the future and spin of multiple threads... if the threadLocal for NOW is not communicated to each thread, they would all come up with their own values again.

          Show
          Yonik Seeley added a comment - Sounds like DateField would the best candidate for holding the ThreadLocal? It might be nice to provide a public static method like public static long getNow() for code that needs the value of NOW w/o going through date math (the ms() function for one) The other question is how the value is set to a particular value passed in on the request (for distributed search sync say). It seems a bit awkward to have something global like SolrCore.execute checking and setting "NOW"... an alternative that could help solve other problems is to have SolrCore.execute set a ThreadLocal<SolrRequest> that things like getNow() could check for a NOW param if it's thread local was not yet set. Another thing to think about: unlike the DateFormatter threadLocal, a NOW threadLocal changes behavior - so it needs to be well defined, and not just a local cache no one else knows about. Example: say that we parallelize some things in the future and spin of multiple threads... if the threadLocal for NOW is not communicated to each thread, they would all come up with their own values again.
          Hide
          Thomas Hammerl added a comment - - edited

          As in SOLR-1709 I'm not able to apply this patch to solr-1.4.0 without getting a compile error:

          [javac] /home/systemone/Desktop/solr-1.4.0/src/java/org/apache/solr/request/SimpleFacets.java:257:
          getCounts(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String)
          in org.apache.solr.request.UnInvertedField cannot be applied to
          (org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String,java.lang.String)
          [javac]         counts = uif.getCounts(searcher, base, offset, limit, mincount,missing,sort,prefix, facetSortOrder);
          

          Is it possible that you have forgotten to include your changes to org.apache.solr.request.UnInvertedField? The method getCounts is missing the facetSortOder parameter you are trying to pass in SimpleFacets.java.

          I would be happy to attach a working patch-file to this issue.

          Show
          Thomas Hammerl added a comment - - edited As in SOLR-1709 I'm not able to apply this patch to solr-1.4.0 without getting a compile error: [javac] /home/systemone/Desktop/solr-1.4.0/src/java/org/apache/solr/request/SimpleFacets.java:257: getCounts(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String) in org.apache.solr.request.UnInvertedField cannot be applied to (org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String,java.lang.String) [javac] counts = uif.getCounts(searcher, base, offset, limit, mincount,missing,sort,prefix, facetSortOrder); Is it possible that you have forgotten to include your changes to org.apache.solr.request.UnInvertedField? The method getCounts is missing the facetSortOder parameter you are trying to pass in SimpleFacets.java. I would be happy to attach a working patch-file to this issue.
          Hide
          Peter Sturge added a comment -

          Hi Thomas,

          Thanks for catching this. I thought I'd attached that one. sigh Honestly, that is really slack of me - many apologies.
          The attached UnInvertedField.java has the updated getCounts() method. Any troubles, let me know.

          Thanks!
          Peter

          Show
          Peter Sturge added a comment - Hi Thomas, Thanks for catching this. I thought I'd attached that one. sigh Honestly, that is really slack of me - many apologies. The attached UnInvertedField.java has the updated getCounts() method. Any troubles, let me know. Thanks! Peter
          Hide
          Thomas Hammerl added a comment -

          Hi Peter!

          No problem! Thanks for contributing the code! I have attached a patch file containing your changes to this issue. Everything compiles fine for me now.

          Thank you too! Greetings,
          Thomas

          Show
          Thomas Hammerl added a comment - Hi Peter! No problem! Thanks for contributing the code! I have attached a patch file containing your changes to this issue. Everything compiles fine for me now. Thank you too! Greetings, Thomas
          Hide
          Peter Karich added a comment -

          Peter Sturge,

          in SOLR-1709 you said that you are working with branch3x I checked it out from here:
          https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x

          but this 1729 patch didn't apply cleanly*.

          When I tried the 1.4.1 release it is ok, but the tests fail due to**

          What could be wrong?

          Regards,
          Peter.

          *
          solr_branch_3x/solr$ patch -p0 < solr-1.4.0-solr-1729.patch
          patching file src/java/org/apache/solr/request/SimpleFacets.java
          Hunk #1 succeeded at 245 (offset 28 lines).
          Hunk #2 succeeded at 280 (offset 28 lines).
          Hunk #3 FAILED at 582.
          Hunk #4 FAILED at 652.
          2 out of 4 hunks FAILED – saving rejects to file src/java/org/apache/solr/request/SimpleFacets.java.rej
          patching file src/java/org/apache/solr/request/UnInvertedField.java
          Hunk #2 succeeded at 40 with fuzz 1 (offset 1 line).
          Hunk #3 succeeded at 440 (offset 5 lines).
          Hunk #4 succeeded at 557 (offset 5 lines).
          patching file src/common/org/apache/solr/common/params/FacetParams.java
          Hunk #1 FAILED at 175.
          1 out of 1 hunk FAILED – saving rejects to file src/common/org/apache/solr/common/params/FacetParams.java.rej

          **
          [junit] Running org.apache.solr.TestTrie
          [junit] xml response was: <?xml version="1.0" encoding="UTF-8"?>
          [junit] <response>
          [junit] <lst name="responseHeader"><int name="status">0</int><int name="QTime">157</int></lst><result name="response" numFound="15" start="0"><doc><float name="id">0.0</float><date name="tdate">2010-12-02T00:00:00Z</date><double name="tdouble">0.0</double><float name="tfloat">0.0</float><int name="tint">0</int><long name="tlong">2147483647</long></doc><doc><float name="id">1.0</float><date name="tdate">2010-12-03T00:00:00Z</date><double name="tdouble">2.33</double><float name="tfloat">31.11</float><int name="tint">1</int><long name="tlong">2147483648</long></doc><doc><float name="id">2.0</float><date name="tdate">2010-12-04T00:00:00Z</date><double name="tdouble">4.66</double><float name="tfloat">124.44</float><int name="tint">2</int><long name="tlong">2147483649</long></doc><doc><float name="id">3.0</float><date name="tdate">2010-12-05T00:00:00Z</date><double name="tdouble">6.99</double><float name="tfloat">279.99</float><int name="tint">3</int><long name="tlong">2147483650</long></doc><doc><float name="id">4.0</float><date name="tdate">2010-12-06T00:00:00Z</date><double name="tdouble">9.32</double><float name="tfloat">497.76</float><int name="tint">4</int><long name="tlong">2147483651</long></doc><doc><float name="id">5.0</float><date name="tdate">2010-12-07T00:00:00Z</date><double name="tdouble">11.65</double><float name="tfloat">777.75</float><int name="tint">5</int><long name="tlong">2147483652</long></doc><doc><float name="id">6.0</float><date name="tdate">2010-12-08T00:00:00Z</date><double name="tdouble">13.98</double><float name="tfloat">1119.96</float><int name="tint">6</int><long name="tlong">2147483653</long></doc><doc><float name="id">7.0</float><date name="tdate">2010-12-09T00:00:00Z</date><double name="tdouble">16.310000000000002</double><float name="tfloat">1524.39</float><int name="tint">7</int><long name="tlong">2147483654</long></doc><doc><float name="id">8.0</float><date name="tdate">2010-12-10T00:00:00Z</date><double name="tdouble">18.64</double><float name="tfloat">1991.04</float><int name="tint">8</int><long name="tlong">2147483655</long></doc><doc><float name="id">9.0</float><date name="tdate">2010-12-11T00:00:00Z</date><double name="tdouble">20.97</double><float name="tfloat">2519.9102</float><int name="tint">9</int><long name="tlong">2147483656</long></doc><doc><float name="id">10.0</float><date name="tdate">2010-12-02T00:00:00Z</date><double name="tdouble">0.0</double><float name="tfloat">0.0</float><int name="tint">0</int><long name="tlong">2147483647</long></doc><doc><float name="id">20.0</float><date name="tdate">2010-12-03T00:00:00Z</date><double name="tdouble">2.33</double><float name="tfloat">31.11</float><int name="tint">1</int><long name="tlong">2147483648</long></doc><doc><float name="id">30.0</float><date name="tdate">2010-12-04T00:00:00Z</date><double name="tdouble">4.66</double><float name="tfloat">124.44</float><int name="tint">2</int><long name="tlong">2147483649</long></doc><doc><float name="id">40.0</float><date name="tdate">2010-12-05T00:00:00Z</date><double name="tdouble">6.99</double><float name="tfloat">279.99</float><int name="tint">3</int><long name="tlong">2147483650</long></doc><doc><float name="id">50.0</float><date name="tdate">2010-12-06T00:00:00Z</date><double name="tdouble">9.32</double><float name="tfloat">497.76</float><int name="tint">4</int><long name="tlong">2147483651</long></doc></result><lst name="facet_counts"><lst name="facet_queries"/><lst name="facet_fields"><lst name="tint"><int name="0">2</int><int name="1">2</int><int name="2">2</int><int name="3">2</int><int name="4">2</int><int name="5">1</int><int name="6">1</int><int name="7">1</int><int name="8">1</int><int name="9">1</int></lst><lst name="tlong"><int name="2147483647">2</int><int name="2147483648">2</int><int name="2147483649">2</int><int name="2147483650">2</int><int name="2147483651">2</int><int name="2147483652">1</int><int name="2147483653">1</int><int name="2147483654">1</int><int name="2147483655">1</int><int name="2147483656">1</int></lst><lst name="tfloat"><int name="0.0">2</int><int name="31.11">2</int><int name="124.44">2</int><int name="279.99">2</int><int name="497.76">2</int><int name="777.75">1</int><int name="1119.96">1</int><int name="1524.39">1</int><int name="1991.04">1</int><int name="2519.9102">1</int></lst><lst name="tdouble"><int name="0.0">2</int><int name="2.33">2</int><int name="4.66">2</int><int name="6.99">2</int><int name="9.32">2</int><int name="11.65">1</int><int name="13.98">1</int><int name="16.310000000000002">1</int><int name="18.64">1</int><int name="20.97">1</int></lst></lst><lst name="facet_dates"><lst name="tdate"><int name="2010-12-02T00:00:00Z">2</int><int name="2010-12-03T00:00:00Z">2</int><int name="2010-12-04T00:00:00Z">2</int><int name="2010-12-05T00:00:00Z">2</int><int name="2010-12-06T00:00:00Z">1</int><int name="2010-12-07T00:00:00Z">1</int><str name="gap">+1DAY</str><date name="end">2010-12-08T00:00:00Z</date></lst></lst></lst>
          [junit] </response>
          [junit]
          [junit] request was: facet.date.start=NOW/DAY&facet=true&q=:&facet.date=tdate&facet.date.gap=%2B1DAY&facet.field=tint&facet.field=tlong&facet.field=tfloat&facet.field=tdouble&facet.date.end=NOW/DAY%2B6DAYS&rows=15)
          [junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 4,948 sec
          [junit] Test org.apache.solr.TestTrie FAILED

          [junit] Running org.apache.solr.request.SimpleFacetsTest
          [junit] xml response was: <?xml version="1.0" encoding="UTF-8"?>
          [junit] <response>
          [junit] <lst name="responseHeader"><int name="status">0</int><int name="QTime">11</int></lst><result name="response" numFound="14" start="0"/><lst name="facet_counts"><lst name="facet_queries"/><lst name="facet_fields"/><lst name="facet_dates"><lst name="bday"><int name="1976-07-01T00:00:00Z">0</int><int name="1976-07-02T00:00:00Z">0</int><int name="1976-07-03T00:00:00Z">2</int><int name="1976-07-04T00:00:00Z">2</int><int name="1976-07-05T00:00:00Z">1</int><int name="1976-07-06T00:00:00Z">0</int><int name="1976-07-07T00:00:00Z">0</int><int name="1976-07-08T00:00:00Z">0</int><int name="1976-07-09T00:00:00Z">0</int><int name="1976-07-10T00:00:00Z">0</int><int name="1976-07-11T00:00:00Z">0</int><int name="1976-07-12T00:00:00Z">1</int><int name="1976-07-13T00:00:00Z">1</int><int name="1976-07-14T00:00:00Z">0</int><int name="1976-07-15T00:00:00Z">2</int><int name="1976-07-16T00:00:00Z">0</int><int name="1976-07-17T00:00:00Z">0</int><int name="1976-07-18T00:00:00Z">0</int><int name="1976-07-19T00:00:00Z">0</int><int name="1976-07-20T00:00:00Z">0</int><int name="1976-07-21T00:00:00Z">1</int><int name="1976-07-22T00:00:00Z">0</int><int name="1976-07-23T00:00:00Z">0</int><int name="1976-07-24T00:00:00Z">0</int><int name="1976-07-25T00:00:00Z">0</int><int name="1976-07-26T00:00:00Z">0</int><int name="1976-07-27T00:00:00Z">0</int><int name="1976-07-28T00:00:00Z">0</int><int name="1976-07-29T00:00:00Z">0</int><int name="1976-07-30T00:00:00Z">1</int><int name="1976-07-31T00:00:00Z">0</int><str name="gap">+1DAY</str><date name="end">1976-08-01T00:00:00Z</date><int name="before">2</int><int name="after">1</int><int name="between">11</int></lst></lst></lst>
          [junit] </response>
          [junit]
          [junit] request was: facet.date.start=1976-07-01T00:00:00.000Z&facet=true&q=:&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00:00:00.000Z%2B1MONTH&rows=0)
          [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 6,996 sec
          [junit] Test org.apache.solr.request.SimpleFacetsTest FAILED

          Show
          Peter Karich added a comment - Peter Sturge, in SOLR-1709 you said that you are working with branch3x I checked it out from here: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x but this 1729 patch didn't apply cleanly*. When I tried the 1.4.1 release it is ok, but the tests fail due to** What could be wrong? Regards, Peter. * solr_branch_3x/solr$ patch -p0 < solr-1.4.0-solr-1729.patch patching file src/java/org/apache/solr/request/SimpleFacets.java Hunk #1 succeeded at 245 (offset 28 lines). Hunk #2 succeeded at 280 (offset 28 lines). Hunk #3 FAILED at 582. Hunk #4 FAILED at 652. 2 out of 4 hunks FAILED – saving rejects to file src/java/org/apache/solr/request/SimpleFacets.java.rej patching file src/java/org/apache/solr/request/UnInvertedField.java Hunk #2 succeeded at 40 with fuzz 1 (offset 1 line). Hunk #3 succeeded at 440 (offset 5 lines). Hunk #4 succeeded at 557 (offset 5 lines). patching file src/common/org/apache/solr/common/params/FacetParams.java Hunk #1 FAILED at 175. 1 out of 1 hunk FAILED – saving rejects to file src/common/org/apache/solr/common/params/FacetParams.java.rej ** [junit] Running org.apache.solr.TestTrie [junit] xml response was: <?xml version="1.0" encoding="UTF-8"?> [junit] <response> [junit] <lst name="responseHeader"><int name="status">0</int><int name="QTime">157</int></lst><result name="response" numFound="15" start="0"><doc><float name="id">0.0</float><date name="tdate">2010-12-02T00:00:00Z</date><double name="tdouble">0.0</double><float name="tfloat">0.0</float><int name="tint">0</int><long name="tlong">2147483647</long></doc><doc><float name="id">1.0</float><date name="tdate">2010-12-03T00:00:00Z</date><double name="tdouble">2.33</double><float name="tfloat">31.11</float><int name="tint">1</int><long name="tlong">2147483648</long></doc><doc><float name="id">2.0</float><date name="tdate">2010-12-04T00:00:00Z</date><double name="tdouble">4.66</double><float name="tfloat">124.44</float><int name="tint">2</int><long name="tlong">2147483649</long></doc><doc><float name="id">3.0</float><date name="tdate">2010-12-05T00:00:00Z</date><double name="tdouble">6.99</double><float name="tfloat">279.99</float><int name="tint">3</int><long name="tlong">2147483650</long></doc><doc><float name="id">4.0</float><date name="tdate">2010-12-06T00:00:00Z</date><double name="tdouble">9.32</double><float name="tfloat">497.76</float><int name="tint">4</int><long name="tlong">2147483651</long></doc><doc><float name="id">5.0</float><date name="tdate">2010-12-07T00:00:00Z</date><double name="tdouble">11.65</double><float name="tfloat">777.75</float><int name="tint">5</int><long name="tlong">2147483652</long></doc><doc><float name="id">6.0</float><date name="tdate">2010-12-08T00:00:00Z</date><double name="tdouble">13.98</double><float name="tfloat">1119.96</float><int name="tint">6</int><long name="tlong">2147483653</long></doc><doc><float name="id">7.0</float><date name="tdate">2010-12-09T00:00:00Z</date><double name="tdouble">16.310000000000002</double><float name="tfloat">1524.39</float><int name="tint">7</int><long name="tlong">2147483654</long></doc><doc><float name="id">8.0</float><date name="tdate">2010-12-10T00:00:00Z</date><double name="tdouble">18.64</double><float name="tfloat">1991.04</float><int name="tint">8</int><long name="tlong">2147483655</long></doc><doc><float name="id">9.0</float><date name="tdate">2010-12-11T00:00:00Z</date><double name="tdouble">20.97</double><float name="tfloat">2519.9102</float><int name="tint">9</int><long name="tlong">2147483656</long></doc><doc><float name="id">10.0</float><date name="tdate">2010-12-02T00:00:00Z</date><double name="tdouble">0.0</double><float name="tfloat">0.0</float><int name="tint">0</int><long name="tlong">2147483647</long></doc><doc><float name="id">20.0</float><date name="tdate">2010-12-03T00:00:00Z</date><double name="tdouble">2.33</double><float name="tfloat">31.11</float><int name="tint">1</int><long name="tlong">2147483648</long></doc><doc><float name="id">30.0</float><date name="tdate">2010-12-04T00:00:00Z</date><double name="tdouble">4.66</double><float name="tfloat">124.44</float><int name="tint">2</int><long name="tlong">2147483649</long></doc><doc><float name="id">40.0</float><date name="tdate">2010-12-05T00:00:00Z</date><double name="tdouble">6.99</double><float name="tfloat">279.99</float><int name="tint">3</int><long name="tlong">2147483650</long></doc><doc><float name="id">50.0</float><date name="tdate">2010-12-06T00:00:00Z</date><double name="tdouble">9.32</double><float name="tfloat">497.76</float><int name="tint">4</int><long name="tlong">2147483651</long></doc></result><lst name="facet_counts"><lst name="facet_queries"/><lst name="facet_fields"><lst name="tint"><int name="0">2</int><int name="1">2</int><int name="2">2</int><int name="3">2</int><int name="4">2</int><int name="5">1</int><int name="6">1</int><int name="7">1</int><int name="8">1</int><int name="9">1</int></lst><lst name="tlong"><int name="2147483647">2</int><int name="2147483648">2</int><int name="2147483649">2</int><int name="2147483650">2</int><int name="2147483651">2</int><int name="2147483652">1</int><int name="2147483653">1</int><int name="2147483654">1</int><int name="2147483655">1</int><int name="2147483656">1</int></lst><lst name="tfloat"><int name="0.0">2</int><int name="31.11">2</int><int name="124.44">2</int><int name="279.99">2</int><int name="497.76">2</int><int name="777.75">1</int><int name="1119.96">1</int><int name="1524.39">1</int><int name="1991.04">1</int><int name="2519.9102">1</int></lst><lst name="tdouble"><int name="0.0">2</int><int name="2.33">2</int><int name="4.66">2</int><int name="6.99">2</int><int name="9.32">2</int><int name="11.65">1</int><int name="13.98">1</int><int name="16.310000000000002">1</int><int name="18.64">1</int><int name="20.97">1</int></lst></lst><lst name="facet_dates"><lst name="tdate"><int name="2010-12-02T00:00:00Z">2</int><int name="2010-12-03T00:00:00Z">2</int><int name="2010-12-04T00:00:00Z">2</int><int name="2010-12-05T00:00:00Z">2</int><int name="2010-12-06T00:00:00Z">1</int><int name="2010-12-07T00:00:00Z">1</int><str name="gap">+1DAY</str><date name="end">2010-12-08T00:00:00Z</date></lst></lst></lst> [junit] </response> [junit] [junit] request was: facet.date.start=NOW/DAY&facet=true&q= : &facet.date=tdate&facet.date.gap=%2B1DAY&facet.field=tint&facet.field=tlong&facet.field=tfloat&facet.field=tdouble&facet.date.end=NOW/DAY%2B6DAYS&rows=15) [junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 4,948 sec [junit] Test org.apache.solr.TestTrie FAILED [junit] Running org.apache.solr.request.SimpleFacetsTest [junit] xml response was: <?xml version="1.0" encoding="UTF-8"?> [junit] <response> [junit] <lst name="responseHeader"><int name="status">0</int><int name="QTime">11</int></lst><result name="response" numFound="14" start="0"/><lst name="facet_counts"><lst name="facet_queries"/><lst name="facet_fields"/><lst name="facet_dates"><lst name="bday"><int name="1976-07-01T00:00:00Z">0</int><int name="1976-07-02T00:00:00Z">0</int><int name="1976-07-03T00:00:00Z">2</int><int name="1976-07-04T00:00:00Z">2</int><int name="1976-07-05T00:00:00Z">1</int><int name="1976-07-06T00:00:00Z">0</int><int name="1976-07-07T00:00:00Z">0</int><int name="1976-07-08T00:00:00Z">0</int><int name="1976-07-09T00:00:00Z">0</int><int name="1976-07-10T00:00:00Z">0</int><int name="1976-07-11T00:00:00Z">0</int><int name="1976-07-12T00:00:00Z">1</int><int name="1976-07-13T00:00:00Z">1</int><int name="1976-07-14T00:00:00Z">0</int><int name="1976-07-15T00:00:00Z">2</int><int name="1976-07-16T00:00:00Z">0</int><int name="1976-07-17T00:00:00Z">0</int><int name="1976-07-18T00:00:00Z">0</int><int name="1976-07-19T00:00:00Z">0</int><int name="1976-07-20T00:00:00Z">0</int><int name="1976-07-21T00:00:00Z">1</int><int name="1976-07-22T00:00:00Z">0</int><int name="1976-07-23T00:00:00Z">0</int><int name="1976-07-24T00:00:00Z">0</int><int name="1976-07-25T00:00:00Z">0</int><int name="1976-07-26T00:00:00Z">0</int><int name="1976-07-27T00:00:00Z">0</int><int name="1976-07-28T00:00:00Z">0</int><int name="1976-07-29T00:00:00Z">0</int><int name="1976-07-30T00:00:00Z">1</int><int name="1976-07-31T00:00:00Z">0</int><str name="gap">+1DAY</str><date name="end">1976-08-01T00:00:00Z</date><int name="before">2</int><int name="after">1</int><int name="between">11</int></lst></lst></lst> [junit] </response> [junit] [junit] request was: facet.date.start=1976-07-01T00:00:00.000Z&facet=true&q= : &facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00:00:00.000Z%2B1MONTH&rows=0) [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 6,996 sec [junit] Test org.apache.solr.request.SimpleFacetsTest FAILED
          Hide
          Peter Sturge added a comment -

          So is 1709 ok, but 1729 isn't?

          Show
          Peter Sturge added a comment - So is 1709 ok, but 1729 isn't?
          Hide
          Peter Karich added a comment -

          regarding: 1.4.1
          Hmmh, today download.carrot2.org is down and I had to delete contrib/clustering to do the build after the patch. which does not apply cleanly (strange that it appled yesterday):

          solr1.4.1$ patch -p0 < solr-1.4.0-solr-1729.patch
          patching file src/java/org/apache/solr/handler/component/FacetComponent.java
          patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java

          solr1.4.1$ patch -p0 < solr-1.4.0-solr-1709.patch
          patching file src/java/org/apache/solr/handler/component/FacetComponent.java
          Reversed (or previously applied) patch detected! Assume -R? [n] y
          patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java
          Reversed (or previously applied) patch detected! Assume -R? [n] y
          Hunk #3 succeeded at 251 (offset -1 lines).

          Or is this ok?? Because then, all tests would pass ...

          regarding branch3x
          both patches do not apply cleanly. SOLR-1709 fails also without SOLR-1729

          solr_branch_3x/solr$ patch -p0 < solr-1.4.0-solr-1709.patch
          patching file src/java/org/apache/solr/handler/component/FacetComponent.java
          Hunk #1 succeeded at 240 (offset 2 lines).
          Hunk #2 succeeded at 267 with fuzz 2 (offset 7 lines).
          Hunk #3 FAILED at 436.
          1 out of 3 hunks FAILED – saving rejects to file src/java/org/apache/solr/handler/component/FacetComponent.java.rej
          patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java
          Reversed (or previously applied) patch detected! Assume -R? [n] y
          Hunk #2 FAILED at 61.
          Hunk #3 FAILED at 252.
          2 out of 3 hunks FAILED – saving rejects to file src/java/org/apache/solr/handler/component/ResponseBuilder.java.rej

          Show
          Peter Karich added a comment - regarding: 1.4.1 Hmmh, today download.carrot2.org is down and I had to delete contrib/clustering to do the build after the patch. which does not apply cleanly (strange that it appled yesterday): solr1.4.1$ patch -p0 < solr-1.4.0-solr-1729.patch patching file src/java/org/apache/solr/handler/component/FacetComponent.java patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java solr1.4.1$ patch -p0 < solr-1.4.0-solr-1709.patch patching file src/java/org/apache/solr/handler/component/FacetComponent.java Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #3 succeeded at 251 (offset -1 lines). Or is this ok?? Because then, all tests would pass ... regarding branch3x both patches do not apply cleanly. SOLR-1709 fails also without SOLR-1729 solr_branch_3x/solr$ patch -p0 < solr-1.4.0-solr-1709.patch patching file src/java/org/apache/solr/handler/component/FacetComponent.java Hunk #1 succeeded at 240 (offset 2 lines). Hunk #2 succeeded at 267 with fuzz 2 (offset 7 lines). Hunk #3 FAILED at 436. 1 out of 3 hunks FAILED – saving rejects to file src/java/org/apache/solr/handler/component/FacetComponent.java.rej patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #2 FAILED at 61. Hunk #3 FAILED at 252. 2 out of 3 hunks FAILED – saving rejects to file src/java/org/apache/solr/handler/component/ResponseBuilder.java.rej
          Hide
          Peter Sturge added a comment -

          Hi Peter,

          Not sure why it would work, then not...

          Both these patches were submitted just before all the version name
          changes (which I'm still getting to grips with).

          At the time, I think 1.4.1 was the latest release train. For 3.x
          recently we've done some manual merging due to some other changes
          (forwarding http credentials to remote shards).

          I'll have a look at building a separate 'branch3x' patch version, as
          there may have been some separate back porting changes in the affected
          files that's breaking the current patch.
          Are you using the latest release, or the latest trunk version?

          Thanks,
          Peter

          Show
          Peter Sturge added a comment - Hi Peter, Not sure why it would work, then not... Both these patches were submitted just before all the version name changes (which I'm still getting to grips with). At the time, I think 1.4.1 was the latest release train. For 3.x recently we've done some manual merging due to some other changes (forwarding http credentials to remote shards). I'll have a look at building a separate 'branch3x' patch version, as there may have been some separate back porting changes in the affected files that's breaking the current patch. Are you using the latest release, or the latest trunk version? Thanks, Peter
          Hide
          Peter Karich added a comment -

          Hi Peter,

          1.4.1 would be fine (I asked Jake from solandra, before I thought he uses the trunk)

          Now in my last comment I made a stupid mistake: the patches didn't cleanly apply for 1.4.1 because I accidentially overwrote solr-1729.patch with solr-1709 when copying from branch3x and got two identical 1709 patches :-/

          So: for 1.4.1 the patches apply cleanly. But the question remains why the following tests are failing:

          Test org.apache.solr.TestTrie FAILED

          Test org.apache.solr.request.SimpleFacetsTest FAILED

          Show
          Peter Karich added a comment - Hi Peter, 1.4.1 would be fine (I asked Jake from solandra, before I thought he uses the trunk) Now in my last comment I made a stupid mistake: the patches didn't cleanly apply for 1.4.1 because I accidentially overwrote solr-1729.patch with solr-1709 when copying from branch3x and got two identical 1709 patches :-/ So: for 1.4.1 the patches apply cleanly. But the question remains why the following tests are failing: Test org.apache.solr.TestTrie FAILED Test org.apache.solr.request.SimpleFacetsTest FAILED
          Hide
          Peter Sturge added a comment -

          Hi Peter,

          So, the patches are clean (for 1.4.1), but the tests are failing for
          1.4.1? Or is the failure in 3.x? Sorry, but I'm a bit confused which
          bit isn't working now.

          Thanks,
          Peter

          On Fri, Dec 3, 2010 at 1:05 PM, Peter Karich (JIRA) <jira@apache.org> wrote:

          Show
          Peter Sturge added a comment - Hi Peter, So, the patches are clean (for 1.4.1), but the tests are failing for 1.4.1? Or is the failure in 3.x? Sorry, but I'm a bit confused which bit isn't working now. Thanks, Peter On Fri, Dec 3, 2010 at 1:05 PM, Peter Karich (JIRA) <jira@apache.org> wrote:
          Hide
          Peter Karich added a comment -

          Hi Peter,

          sorry for the confusion :-/

          I was speaking of 1.4.1: the two patches apply. 2 tests fail.

          Regards,
          Peter.

          Show
          Peter Karich added a comment - Hi Peter, sorry for the confusion :-/ I was speaking of 1.4.1: the two patches apply. 2 tests fail. Regards, Peter.
          Hide
          Yonik Seeley added a comment -

          Here's a patch for trunk that uses a thread local to make "NOW" the same across all uses,
          and is overridable by passing NOW=<ms> in the request params.

          You can see it working with a request like:
          http://localhost:8983/solr/select?q=

          {!func}

          ms%28NOW%29&fl=id,score&NOW=1000

          This does not yet handle propagating NOW to shards in a distributed search.

          Show
          Yonik Seeley added a comment - Here's a patch for trunk that uses a thread local to make "NOW" the same across all uses, and is overridable by passing NOW=<ms> in the request params. You can see it working with a request like: http://localhost:8983/solr/select?q= {!func} ms%28NOW%29&fl=id,score&NOW=1000 This does not yet handle propagating NOW to shards in a distributed search.
          Hide
          Yonik Seeley added a comment -

          OK, here's an updated patch that propagates NOW for all shard requests. It seemed too risky to try and detect when NOW would be needed.

          Show
          Yonik Seeley added a comment - OK, here's an updated patch that propagates NOW for all shard requests. It seemed too risky to try and detect when NOW would be needed.
          Hide
          Peter Karich added a comment -

          Yonik,

          thanks for the update. I refreshed my sources (now trunk) to rev 1044745. But the patch does not cleanly apply* for SearchHandler.
          Am I doing something stupid here?

          Regards,
          Peter.

          *
          pathxy/solr_branch_3x$ patch -p0 < SOLR-1729.patch
          patching file solr/src/test/test-files/solr/conf/schema12.xml
          patching file solr/src/test/org/apache/solr/search/function/TestFunctionQuery.java
          Hunk #1 succeeded at 301 (offset -17 lines).
          patching file solr/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java
          patching file solr/src/test/org/apache/solr/handler/component/TermVectorComponentTest.java
          patching file solr/src/java/org/apache/solr/core/QuerySenderListener.java
          patching file solr/src/java/org/apache/solr/request/SimpleFacets.java
          Hunk #1 succeeded at 64 (offset -9 lines).
          Hunk #2 succeeded at 620 (offset -200 lines).
          Hunk #3 succeeded at 630 (offset -200 lines).
          Hunk #4 succeeded at 645 (offset -200 lines).
          Hunk #5 succeeded at 803 (offset -200 lines).
          patching file solr/src/java/org/apache/solr/handler/component/SearchHandler.java
          Hunk #1 FAILED at 192.
          Hunk #2 succeeded at 255 (offset -36 lines).
          1 out of 2 hunks FAILED – saving rejects to file solr/src/java/org/apache/solr/handler/component/SearchHandler.java.rej
          patching file solr/src/java/org/apache/solr/handler/component/ResponseBuilder.java
          Hunk #2 succeeded at 67 (offset -1 lines).
          patching file solr/src/java/org/apache/solr/spelling/SpellCheckCollator.java
          patching file solr/src/java/org/apache/solr/util/TestHarness.java
          Hunk #2 succeeded at 320 (offset -9 lines).
          Hunk #3 succeeded at 335 (offset -9 lines).
          patching file solr/src/java/org/apache/solr/util/DateMathParser.java
          patching file solr/src/webapp/src/org/apache/solr/servlet/SolrServlet.java
          patching file solr/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
          Hunk #1 succeeded at 241 (offset 4 lines).
          Hunk #2 succeeded at 255 (offset 4 lines).
          Hunk #3 succeeded at 283 (offset 4 lines).
          patching file solr/src/webapp/src/org/apache/solr/servlet/DirectSolrConnection.java
          Hunk #2 succeeded at 170 (offset -16 lines).
          Hunk #3 succeeded at 185 with fuzz 1 (offset -16 lines).
          patching file solr/src/webapp/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
          Hunk #1 succeeded at 32 with fuzz 1 (offset -9 lines).
          Hunk #2 succeeded at 138 (offset -11 lines).
          Hunk #3 succeeded at 156 (offset -77 lines).

          Show
          Peter Karich added a comment - Yonik, thanks for the update. I refreshed my sources (now trunk) to rev 1044745. But the patch does not cleanly apply* for SearchHandler. Am I doing something stupid here? Regards, Peter. * pathxy/solr_branch_3x$ patch -p0 < SOLR-1729 .patch patching file solr/src/test/test-files/solr/conf/schema12.xml patching file solr/src/test/org/apache/solr/search/function/TestFunctionQuery.java Hunk #1 succeeded at 301 (offset -17 lines). patching file solr/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java patching file solr/src/test/org/apache/solr/handler/component/TermVectorComponentTest.java patching file solr/src/java/org/apache/solr/core/QuerySenderListener.java patching file solr/src/java/org/apache/solr/request/SimpleFacets.java Hunk #1 succeeded at 64 (offset -9 lines). Hunk #2 succeeded at 620 (offset -200 lines). Hunk #3 succeeded at 630 (offset -200 lines). Hunk #4 succeeded at 645 (offset -200 lines). Hunk #5 succeeded at 803 (offset -200 lines). patching file solr/src/java/org/apache/solr/handler/component/SearchHandler.java Hunk #1 FAILED at 192. Hunk #2 succeeded at 255 (offset -36 lines). 1 out of 2 hunks FAILED – saving rejects to file solr/src/java/org/apache/solr/handler/component/SearchHandler.java.rej patching file solr/src/java/org/apache/solr/handler/component/ResponseBuilder.java Hunk #2 succeeded at 67 (offset -1 lines). patching file solr/src/java/org/apache/solr/spelling/SpellCheckCollator.java patching file solr/src/java/org/apache/solr/util/TestHarness.java Hunk #2 succeeded at 320 (offset -9 lines). Hunk #3 succeeded at 335 (offset -9 lines). patching file solr/src/java/org/apache/solr/util/DateMathParser.java patching file solr/src/webapp/src/org/apache/solr/servlet/SolrServlet.java patching file solr/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java Hunk #1 succeeded at 241 (offset 4 lines). Hunk #2 succeeded at 255 (offset 4 lines). Hunk #3 succeeded at 283 (offset 4 lines). patching file solr/src/webapp/src/org/apache/solr/servlet/DirectSolrConnection.java Hunk #2 succeeded at 170 (offset -16 lines). Hunk #3 succeeded at 185 with fuzz 1 (offset -16 lines). patching file solr/src/webapp/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java Hunk #1 succeeded at 32 with fuzz 1 (offset -9 lines). Hunk #2 succeeded at 138 (offset -11 lines). Hunk #3 succeeded at 156 (offset -77 lines).
          Hide
          Yonik Seeley added a comment -

          pathxy/solr_branch_3x$ patch -p0 < SOLR-1729.patch

          The patch was for trunk, not 3x?

          Show
          Yonik Seeley added a comment - pathxy/solr_branch_3x$ patch -p0 < SOLR-1729 .patch The patch was for trunk, not 3x?
          Hide
          Peter Karich added a comment -

          Hi Yonik,

          so, sorry for another misposting: yes, you were right. it was the wrong solr version. it was too late yesterday :-/

          All is fine now with this patch. But the org.apache.solr.request.SolrRequestInfo class is missing or am I completely crazy now? (I checked out solr twice and applied the patch again but it didn't compile)

          Regards,
          Peter.

          Show
          Peter Karich added a comment - Hi Yonik, so, sorry for another misposting: yes, you were right. it was the wrong solr version. it was too late yesterday :-/ All is fine now with this patch. But the org.apache.solr.request.SolrRequestInfo class is missing or am I completely crazy now? (I checked out solr twice and applied the patch again but it didn't compile) Regards, Peter.
          Hide
          Yonik Seeley added a comment -

          Yep, I forgot to "svn add" the new file.
          Here's a hopefully working patch.

          Show
          Yonik Seeley added a comment - Yep, I forgot to "svn add" the new file. Here's a hopefully working patch.
          Hide
          Peter Karich added a comment -

          Nice, now this patch 1729 applies + compiles + run tests successfully (I'm using rev 1044942 of trunk)

          One further question: Would facet queries (with dates) work in the distributed setup without the date-patches? To get a quick(er) workaround. because I would need the patch for 1.4.1 (->solandra)

          Show
          Peter Karich added a comment - Nice, now this patch 1729 applies + compiles + run tests successfully (I'm using rev 1044942 of trunk) One further question: Would facet queries (with dates) work in the distributed setup without the date-patches? To get a quick(er) workaround. because I would need the patch for 1.4.1 (->solandra)
          Hide
          Yonik Seeley added a comment -

          Would facet queries (with dates) work in the distributed setup without the date-patches?

          I'm not sure which date-patches you refer to, but this should fix all issues related to NOW being different in different places (both distributed and non distributed).

          Show
          Yonik Seeley added a comment - Would facet queries (with dates) work in the distributed setup without the date-patches? I'm not sure which date-patches you refer to, but this should fix all issues related to NOW being different in different places (both distributed and non distributed).
          Hide
          Yonik Seeley added a comment -

          I added a test for distributed search and committed.

          Show
          Yonik Seeley added a comment - I added a test for distributed search and committed.
          Hide
          Peter Sturge added a comment -

          Many thanks for finishing off this patch. Sorry I didn't get time to fix this, been swamped with so many projects at the moment.
          That's great you got the thread local NOW included as well. Thanks!

          Show
          Peter Sturge added a comment - Many thanks for finishing off this patch. Sorry I didn't get time to fix this, been swamped with so many projects at the moment. That's great you got the thread local NOW included as well. Thanks!
          Hide
          Simon Willnauer added a comment -

          I am planning to backport SOLR-1709 to 3.x and apparently its a good idea to do the same for this issue. Any objections & issues what I should be aware of with this issue?

          Show
          Simon Willnauer added a comment - I am planning to backport SOLR-1709 to 3.x and apparently its a good idea to do the same for this issue. Any objections & issues what I should be aware of with this issue?
          Hide
          David Smiley added a comment -

          Fantastic Simon! I'm glad someone with clout (i.e. a committer) is willing to make this happen. Users need SOLR-1709.

          Show
          David Smiley added a comment - Fantastic Simon! I'm glad someone with clout (i.e. a committer) is willing to make this happen. Users need SOLR-1709 .
          Hide
          Simon Willnauer added a comment -

          reopen for backport to 3x

          Show
          Simon Willnauer added a comment - reopen for backport to 3x
          Hide
          Simon Willnauer added a comment -

          here is a patch created from my svn merge. I also added SorlRequestInfo to places where it was added outside of this issue in 4.x. I'd appreciate a review but it seems all tests pass.

          Show
          Simon Willnauer added a comment - here is a patch created from my svn merge. I also added SorlRequestInfo to places where it was added outside of this issue in 4.x. I'd appreciate a review but it seems all tests pass.
          Hide
          Simon Willnauer added a comment -

          updated patch, I accidentally remove some lines from a test. they are back now and the patch includes the updated CHANGES.TXT

          Show
          Simon Willnauer added a comment - updated patch, I accidentally remove some lines from a test. they are back now and the patch includes the updated CHANGES.TXT
          Hide
          Simon Willnauer added a comment -

          I am going to commit this soon if nobody objects.

          Show
          Simon Willnauer added a comment - I am going to commit this soon if nobody objects.
          Hide
          Simon Willnauer added a comment -

          backported to 3x in rev 1232343

          Show
          Simon Willnauer added a comment - backported to 3x in rev 1232343

            People

            • Assignee:
              Simon Willnauer
              Reporter:
              Peter Sturge
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development