Since using REPLACE or INSERT...ON DUPLICATE KEY
statements both give us affected rows of 1 for a
new row or a row which got updated with the same
values, we make isNewInstance undefined on after
save hook for save, replaceOrCreate, and
updateOrCreate methods. Also, disable juggler
tests for that functionality.
When converting null values
to database column values,
return null if column is
nullable, otherwise try
to cast it to the property
type, and if not, return
'null'.
MySQL expects reverse order of latitude and longitude
from the way we use it in LoopBack, so switch the order
when saving and loading Point spatial type we use for
Point/GeoPoint.
This commit contains all previous work after rebase went badly
RE: Pull Request requested by @kjdelisle regarding #149 following my
proposed solution "A" at #149 (comment).
As mentioned in the post linked above, this change allows the
underlying mysqljs/mysql module to handle Date object serialization
and removes the forced conversion of Dates to UTC Strings.
An opt-out fallback to forced coercion to UTC is included,
which was modeled after #265 from @darknos .
Old, squashed commits:
d0ea1d926eae04d0355109c87eef4eeec173f887
Legacy UTC date processing fallback credit: @darknos
a59dad7d7bd945895fb410a963cf5932b6a20f9e
Remove orphaned string functions
e8fdbdcfd4092f3d9e018f688d14def3e3ca9856
Incorporate @darknos expanded check for zero dates
abd4e0a7e9122f857974678a6b6ad87a19988f6f
Remove DATE manipulations in from/toColumnValue
* refactor date, timestamp, datetime data-type
* reverse datatypes.test.js changes
* checking property.mysql.dataType
along with property.dataType for timestamp fields
* Fix PR linter
* moved test cases all under one test file
remove unnecessary test cases, unify setup procedures
* Fix sql mode before migration
Set sql mode to allow zero's on timestamp
Clean up code
* remove test cases with strings and DATE field type
* code cleanup as requested
* add accidentally deleted assert.ok(found)
* fix timeZone to timezone case in README.md
* Update readme with date type info
Per MySQL docs
(http://dev.mysql.com/doc/refman/5.7/en/date-and-time-types.html):
"MySQL permits you to store a “zero” value of '0000-00-00' as a
“dummy date.” This is in some cases more convenient than using NULL
values, and uses less data and index space. To disallow '0000-00-00',
enable the NO_ZERO_DATE mode.
“Zero” date or time values used through Connector/ODBC are converted
automatically to NULL because ODBC cannot handle such values."
As we are not using Connector/ODBC we need to handle this ourself.
Diana Lau
jannyHou
Antonio Trapani
Agnes Lin
biniam
ssh24
Kevin Delisle
Joost de Bruijn
Buck Bito
Sakib Hasan
Sergey Nosenko
juanra
Raymond Feng
Loay
Carl Fürstenberg
Candy
Ryan Graham
Amir Jafarian
Diogo Correia
Simon Ho
Raymond Feng
ulion
Geoffroy Lesage
cpentra1
yogesh