THomas,
Thanks very much for making the patch files - very much appreciated! Peter > Date: Wed, 17 Feb 2010 13:09:27 +0000 > From: j...@apache.org > To: solr-dev@lucene.apache.org > Subject: [jira] Updated: (SOLR-1729) Date Facet now override time parameter > > > [ > https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Thomas Hammerl updated SOLR-1729: > --------------------------------- > > Attachment: solr-1.4.0-solr-1729.patch > > 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 > > > Date Facet now override time parameter > > -------------------------------------- > > > > Key: SOLR-1729 > > URL: https://issues.apache.org/jira/browse/SOLR-1729 > > Project: Solr > > Issue Type: Improvement > > Components: search > > Affects Versions: 1.4 > > Environment: Solr 1.4 > > Reporter: Peter Sturge > > Priority: Minor > > Attachments: FacetParams.java, SimpleFacets.java, > > solr-1.4.0-solr-1729.patch, UnInvertedField.java > > > > > > 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. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > _________________________________________________________________ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
