[
https://issues.apache.org/jira/browse/LUCENE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338957#comment-14338957
]
Ryan Ernst commented on LUCENE-6302:
------------------------------------
I agree with Robert, we don't need date math. We should stay with a subset of
javascript, and have functions to help alleviate pain in dealing with epochs.
I also agree now() should be handled with a variable instead of a function.
Regarding parse methods, I think these should be for constants, not parsing
from string fields. Parsing is slow, it shouldn't happen for every document.
You can do these outside of the expression and place in variables. It might be
possible we could have some functions optimized to execute once (e.g.
{{Date.parse("2015-01-01")}} which wouldn't change per document). For date
parts, I think this can already be handled with variables as well. We have
{{VariableContext}} which allows binding something like {{mydatevar.month}} to
a different value source than {{mydatevar}}. So we could have helper value
sources that operate on epochs and extract year, month, etc.
> Adding Date Math support to Lucene Expressions module
> -----------------------------------------------------
>
> Key: LUCENE-6302
> URL: https://issues.apache.org/jira/browse/LUCENE-6302
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/expressions
> Affects Versions: 4.10.3
> Reporter: Itamar Syn-Hershko
>
> Lucene Expressions are great, but they don't allow for date math. More
> specifically, they don't allow to infer date parts from a numeric
> representation of a date stamp, nor they allow to parse strings
> representations to dates.
> Some of the features requested here easy to implement via ValueSource
> implementation (and potentially minor changes to the lexer definition) , some
> are more involved. I'll be happy if we could get half of those in, and will
> be happy to work on a PR for the parts we can agree on.
> The items we will be happy to have:
> - A now() function (with or without TZ support) to return a current long
> date/time value as numeric, that we could use against indexed datetime fields
> (which are infact numerics)
> - Parsing methods - to allow to express datetime as strings, and / or read it
> from stored fields and parse it from there. Parse errors would render a value
> of zero.
> - Given a numeric value, allow to specify it is a date value and then infer
> date parts - e.g. Date(1424963520).Year == 2015, or Date(now()) -
> Date(1424963520).Year. Basically methods which return numerics but internally
> create and use Date objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
