Hi team,
I like the Oct2020 release very much.
It has some discontinuities with past releases, and that's ok.
One that I find a bit too painful though is the stricter time and interval typing. Not that I am against it, it is now more SQL compliant. But perhaps the transition could have been a bit softer.
It boils down to date arithmetics between temporal and numeric types.
Something like this was allowed before:
1 + (date1 - date2) (integer + interval)
As the release notes say, a new function epoch_ms() has been added to help the transition. This function can turn dates and intervals into the number (int) of milliseconds since 1970-01-01 00:00:00 UTC.
So if one really needs such arithmetics, could do something like
1 + epoch_ms(date1 - date2)
The problem with this is that this function was not available in earlier releases. This makes the migration of existing applications very hard, because there is no combination that works in all cases:
Deployed application Old MonetDB New MonetDB int + interval works fails int + cast(interval as int) works fails int + epoch_ms(interval) fails works
As you see, there is no overlap between the solutions that worked with MonetDB < Oct2020 and those that work with MonetDB Oct2020.
I wonder, would it have been such a bad idea to make the transition as it was done, but leave the ability to cast an interval to a number? At least for a couple of releases?
We are now facing the issue that if we want to roll forward to MonetDB Oct2020, at the same time we need to make sure to redeploy our code to be compatible with it. There is so much that could go wrong with this! It's scary. I've nothing against breaking backward compatibility, but honestly I don't see the urgency in removing that cast, it would have helped a lot.
Roberto Cornacchia +31 (0) 6 27 232 270 www.spinque.com
Could you use the function "second": select "second"(interval '10' second); -> 10
You need the quotes.
On 03/11/2020 15.20, Roberto Cornacchia wrote:
Hi team,
I like the Oct2020 release very much.
It has some discontinuities with past releases, and that's ok.
One that I find a bit too painful though is the stricter time and interval typing. Not that I am against it, it is now more SQL compliant. But perhaps the transition could have been a bit softer.
It boils down to date arithmetics between temporal and numeric types.
Something like this was allowed before:
1 + (date1 - date2) (integer + interval)
As the release notes say, a new function epoch_ms() has been added to help the transition. This function can turn dates and intervals into the number (int) of milliseconds since 1970-01-01 00:00:00 UTC.
So if one really needs such arithmetics, could do something like
1 + epoch_ms(date1 - date2)
The problem with this is that this function was not available in earlier releases. This makes the migration of existing applications very hard, because there is no combination that works in all cases:
Deployed application Old MonetDB New MonetDB int + interval works fails int + cast(interval as int) works fails int + epoch_ms(interval) fails works
As you see, there is no overlap between the solutions that worked with MonetDB < Oct2020 and those that work with MonetDB Oct2020.
I wonder, would it have been such a bad idea to make the transition as it was done, but leave the ability to cast an interval to a number? At least for a couple of releases?
We are now facing the issue that if we want to roll forward to MonetDB Oct2020, at the same time we need to make sure to redeploy our code to be compatible with it. There is so much that could go wrong with this! It's scary. I've nothing against breaking backward compatibility, but honestly I don't see the urgency in removing that cast, it would have helped a lot.
Roberto Cornacchia +31 (0) 6 27 232 270 www.spinque.com http://www.spinque.com/
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
On Tue, 3 Nov 2020 at 16:49, Sjoerd Mullender sjoerd@monetdb.org wrote:
Could you use the function "second": select "second"(interval '10' second); -> 10
You need the quotes.
But with an older MonetDB, "second"(date1 - date2) would be "second" of an integer, which makes no sense.
Of course also the cast would not solve everything, because it wouldn't solve the underlying fact that, for example, a date difference returns days (int) in one case and a second interval in the other. So it's not only the formal type that has changed, but also the scale. Still one could argue that the cast is transparent. You just change the formal type and you deal with the scale.
In the meantime I also got some more details about why keeping the cast would have been problematic, which I understand.
It's unfortunate that this change implies a difficult redeployment strategy of the existing applications, but maybe it was indeed hard to avoid this time.
You're right. Doesn't work.
On 03/11/2020 17.14, Roberto Cornacchia wrote:
On Tue, 3 Nov 2020 at 16:49, Sjoerd Mullender <sjoerd@monetdb.org mailto:sjoerd@monetdb.org> wrote:
Could you use the function "second": select "second"(interval '10' second); -> 10 You need the quotes.But with an older MonetDB, "second"(date1 - date2) would be "second" of an integer, which makes no sense.
Of course also the cast would not solve everything, because it wouldn't solve the underlying fact that, for example, a date difference returns days (int) in one case and a second interval in the other. So it's not only the formal type that has changed, but also the scale. Still one could argue that the cast is transparent. You just change the formal type and you deal with the scale.
In the meantime I also got some more details about why keeping the cast would have been problematic, which I understand.
It's unfortunate that this change implies a difficult redeployment strategy of the existing applications, but maybe it was indeed hard to avoid this time.
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (3)
-
Roberto Cornacchia -
Roberto Cornacchia -
Sjoerd Mullender