Replies: 21 comments
-
Seems to be a documentation issue. If you explicitly cast to a datetime, there isn't an issue: If the documentation simply adds the cast, it will work. CREATE person SET
birthday = <datetime> "2007-06-22",
can_drive = <future> { time::now() > birthday + 18y } |
Beta Was this translation helpful? Give feedback.
-
@JonahPlusPlus why isn't a date also a datetime though (a sub type where time is 00:00:00 for instance) like in many regular databases ? I would expect |
Beta Was this translation helpful? Give feedback.
-
@cscetbon It's possible that it's a mistake when parsing (Looking at this file, it seems that when parsing a datetime, they could have used |
Beta Was this translation helpful? Give feedback.
-
I think this is something for you to look at @tobiemh @DelSkayn @kearfy . Assigning to @DelSkayn for the time being, but that can be changed. |
Beta Was this translation helpful? Give feedback.
-
I did know about this behavior. "2007-06-22" is just a normal string, and wont be parsed as a date-time. I don't know the rational for why this is the case but we can't change this right now since that would be a breaking change. Possibly silently changing the type of some kinds of strands to a different type. We can change the behavior of prefix strands, or Datetime prefixed strands currently only parse if the non-prefixed strand would parse to a datetime. But we could allow it to be more general which I think it should. |
Beta Was this translation helpful? Give feedback.
-
Why would you need to prefix it in this case ? The fact that 2 operands (date and interval) are added should trigger a conversion or a cast attempt IMO. |
Beta Was this translation helpful? Give feedback.
-
Well, the 2 operand aren't a date and an interval but a string and an interval. So for the addition to work, without a cast or a string prefix, the string would need to be implicitly converted to a datetime. I am not sure if that is the right solution. Implicit conversion between types can be a bit of a footgun. |
Beta Was this translation helpful? Give feedback.
-
We're saying the same thing except you disagree 🤣. I suppose that if someone adds an interval to a string it's because that string is a date. If it's correctly parsed then the operation succeeds otherwise it fails. But tbh I don't know what would be the complexity in adding an implicit cast here and if there are known cases where it would be a problem. Other databases don't have an issue with this so it seems that not diverging, at least on this, makes sense to me. |
Beta Was this translation helpful? Give feedback.
-
IMO any string being automatically casted to a datetime, record ID, uuid, etc is... not favorable, let alone just We are working on a very nice CBOR protocol which will allow us to have native types in X SDK (Thing/RecordID, Date, Uuid, etc...) interface directly to native SurrealQL types, which will great improve things around this subject :) |
Beta Was this translation helpful? Give feedback.
-
Your definition of what is a datetime and what is based on what you think it looks like a datetime. When I say that it is string I mean that it is parsed as a string and the type of that expression is a string.
It is correctly parsed as a string, IMO strands without a prefix should never parse to a datetime, and we are also moving towards that with the new parser. With the current way strings can suddenly change to other types if they happen to match that type. This is already a problem with people encountering queries which fail only for some values of strings.
SurrealQL is far more general then a lot of query languages out there. When you add implicit casting you end with all the problems that javascript and it's implicit casting has. Where values can sudden end up as values with completely different types with different behavior.
Basically any database I know requires you to write |
Beta Was this translation helpful? Give feedback.
-
In the case I'm talking about an interval can only be added to a date/datetime so it makes perfectly sense and doesn't need to be explicit.
What about MySQL 😉 ?
|
Beta Was this translation helpful? Give feedback.
-
@kearfy what does the timezone have to do with a cast here ? what difference would a |
Beta Was this translation helpful? Give feedback.
-
Different regions might have different standards. Obviously you would only accept one format, but I rather meant it as an example of "where do you draw the line?" |
Beta Was this translation helpful? Give feedback.
-
I could make just as much an argument for why the result of
Never used MySQL but looking into it the database has implicit casting. And the behavior you want is the result of broad implicit type casting. This is a type of design that made sense in when MySQL and Javascript where designed but is now broadly considered bad design. We don't want to introduce footguns where giving a function the wrong type results in a cascade of implicit type casts where you end up with unpredictable results. |
Beta Was this translation helpful? Give feedback.
-
I was talking about casting strings that are added to dates/interval as dates, not casting anything to everything. This is a bad argument to discard the proposal IMO.
So why ask if you were no matter what going to discard the need ? You should tell this to Oracle and the MySQL community. I think we can say that we completely disagree. You can close the issue if it's just not up for debate. |
Beta Was this translation helpful? Give feedback.
-
I am not trying to slippery slope. So far your argument is that you think it makes sense that a string be cast here and therefore it should. I intended to show that that is not an argument.
I was honestly surprised that there was a database out there which choose this kind of design. I was only familiar with db which are more explicit for types. I would think that, with a database, you want to really make sure you are explicit about what is actually stored. Maybe I was a bit to harsh, in calling it
That seems to be the case, however, I am not solely in charge of the design of SurrealQL, surrealdb and its community are. I have just argued that I think we shouldn't support this. If your arguments are convincing enough that others would agree with you I won't object. |
Beta Was this translation helpful? Give feedback.
-
okay let's see how it goes. In my opinion it should be supported for simplicity, because it makes sense, and because I don't think that's a situation that could be confusing to anyone. |
Beta Was this translation helpful? Give feedback.
-
i don't know why you insist on casting the string to a date , you can just use a helper function to parse/convert or explicitly declare its type , using the auto cast syntax is just lazy and also bad for the design. |
Beta Was this translation helpful? Give feedback.
-
@samdace If you read this whole thread I already made my case so not sure why I'm being asked again, but here were my arguments :
|
Beta Was this translation helpful? Give feedback.
-
I moved this from an issue into a discussions since this is less about a bug in surrealdb and more about design philosophy, and whether to support implicit conversion. I changed the title to what I think this thread is about, cscetbon feel free to change it if you think it does not reflect your request. |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
addition can't be done between date and interval
Steps to reproduce
Follow documentation at https://docs.surrealdb.com/docs/surrealql/datamodel/futures#futures-depending-on-other-fields doesn't work
Same when doing
Expected behaviour
SurrealDB version
1.0.2+20231221.0f549fb.dirty
Contact Details
No response
Is there an existing issue for this?
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions