On Thu, Dec 1, 2016 at 11:09 AM, Sylvain Lebresne <sylv...@datastax.com> wrote:
> On Thu, Dec 1, 2016 at 4:44 PM, Edward Capriolo <edlinuxg...@gmail.com> > wrote: > >> >> I am not sure you saw my reply on thread but I believe everyone's needs >> can be met I will copy that here: >> > > I saw it, but the real problem that was raised initially was not that of > UDF and of allowing both behavior. It's a matter of people being confused > by the behavior of a non-UDF function, now(), and suggesting it should be > changed. > > The Hive idea is interesting I guess, and we can switch to discussing > that, but it's a different problem really and I'm not a fond of derailing > threads. I will just note though that if we're not talking about a > confusion issue but rather how to get a timeuuid to be fixed within a > statement, then there is much much more trivial solution: generate it > client side. The `now()` function is a small convenience but there is > nothing you cannot do without it client side, and that actually basically > stands for almost any use of (non aggregate) function in Cassandra > currently. > > >> >> >> "Food for thought: Hive's UDFs introduced an annotation >> @UDFType(deterministic = false) >> >> http://dmtolpeko.com/2014/10/15/invoking-stateful-udf-at-map >> -and-reduce-side-in-hive/ >> >> The effect is the query planner can see when such a UDF is in use and >> determine the value once at the start of a very long query." >> >> Essentially hive had a similar if not identical problem, during a long >> running distributed process like map/reduce some users wanted the semantics >> of: >> >> 1) Each call should have a new timestamps >> >> While other users wanted the semantics of: >> >> 2) Each call should generate the same timestamp >> >> The solution implemented was to add an annotation to udf such that the >> query planner would pick up the annotation and act accordingly. >> >> (Here is a related issue https://issues.apache.org/jira/browse/HIVE-1986 >> >> As a result you can essentially implement two UDFS >> >> @UDFType(deterministic = false) >> public class UDFNow >> >> and for the other people >> >> @UDFType(deterministic = true) >> public class UDFNowOnce extends UDFNow >> >> Both user cases are met in a sensible way. >> > > I agree that changing the semantics of something already in existence is a bad idea. What is there "now" no pun on works should stay working as is. I will also point out that presto addresses this issue with specific functions: https://prestodb.io/docs/current/functions/datetime.html localtime -> time Returns the current time as of the start of the query. localtimestamp -> timestamp Returns the current timestamp as of the start of the query.
