shamim8888 / asterixdb

Automatically exported from code.google.com/p/asterixdb
0 stars 0 forks source link

current-datetime() needs a little more documentation #890

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
It can lead to potentially undesired behavior that two calls of 
current-datetime() within a transaction can yield different timestamps. It 
seems like the current-datetime should be built into the context as the start 
time of the transaction.

Original issue reported on code.google.com by sjaco...@ucr.edu on 29 May 2015 at 4:45

GoogleCodeExporter commented 8 years ago
Q: Can you clarify what you mean by transaction?  (I'm being serious.)  What 
would the time/control scope be that you envision?

Original comment by dtab...@gmail.com on 29 May 2015 at 4:59

GoogleCodeExporter commented 8 years ago
That's a good question :) I think at a minimum it would be nice if each 
compiled statement had a single current-datetime(). 

For example, suppose we did an insert statement that inserted several records, 
all using current-datetime(). I think we would want these to be the same (of 
course the query could be written better to only use a single call to 
current-datetime(), but the user might not be thinking about that).

I do think there are also reasons to be consistent across statements, but this 
may be a more difficult problem.

Original comment by sjaco...@ucr.edu on 29 May 2015 at 5:11

GoogleCodeExporter commented 8 years ago
Per our discussion, it seems that we shouldn't make the assumption that a user 
intends to make current-datetime() the same across subsequent calls. We do, 
however, need to specify in the documentation that a user should understand 
this when using current-datetime(). 

Original comment by sjaco...@ucr.edu on 29 May 2015 at 5:37

GoogleCodeExporter commented 8 years ago
And we might need to extend our insert/delete syntax to allow for let clauses?

Original comment by dtab...@gmail.com on 29 May 2015 at 8:22

GoogleCodeExporter commented 8 years ago
That's another great point. There would be no way with things as they are to 
insert multiple records and guarantee the same timestamp.

Original comment by sjaco...@ucr.edu on 29 May 2015 at 8:32