Yeah I know Dave. But, around what Colin found, if the underlying lib decides to change the default, we have no power over that. Was just a suggestion for a feature request to allow the user to chose by adding an option in the config node. My feeling is something somewhere changed (under the hood in a dep) and when the op updated, he got this "something" newer that had changed somehow.
@rakgupta, did you do anything related to the mysql server? Changing anything in its config for example.
Have you got a backup of the package-lock.json from when it all worked? If so have a look in there and find the entry for node-red-node-mysql, which will tell you what version it was using. Under that you should see the version of the mysql package that it was using. Then have a look in the latest and see what versions they are now.
I can't easily test it myself at the moment, but that doesn't sound right. Everything I can find suggests that TIMESTAMP fields should come back as Date Objects.
indeed - that seems to be the "problem" - I have a simple table that auto adds a timestamp field and that currently comes back as a string.
And indeed I needed more coffee when updating it this morning... basically a no-op... now 0.1.6 def returns date type for the timestamp.
Is it available? I wanted to test this out but it is not showing as an available update.
If it isn't showing in the browser then, in a terminal, go into your .node-red folder (that is important) and run
npm install node-red-node-mysql
That might take a little while. At the end it will tell you which version it installed.
Then restart node-red.
Phew. Apologies for the disruption, and thanks for reporting it
