Closed ryanalbrecht closed 2 months ago
Looks like you have some failures on Adobe engines to check.
@elpete There are two different issue at play here with this pull request. The first is an easy one. Adobe released a patch yesterday which changes the default encryption algorithm for the hash()
function. This was a simple fix
The other is more nuanced. Mysql, by default does not store the millisecond part of a timestamp
field. To enable this you have to specify a precision on the column definition such as timestamp(1), timestamp(2), timestamp(3)
etc. The reason these tests are failing is because qb will output date binding with a format that include the millisecond part (dateTimeFormat( value, "yyyy-mm-dd HH:nn:ss.lll" )
. This will cause Mysql to round to the nearest second when saving it. This sometimes causes a mismatch when comparing the provided vs stored value.
Not a 100% sure how to proceed on this. What are you thoughts?
I think we do this in two parts:
raw
function should let you do that.timestamp
and datetime
columns to have millisecond precision.Copy that. Will get to work on this
I changed the migration for the 'songs' table to be created using the raw
function. I also added changes for qb.
Thank you!
In relation to auto-incrementing fields MySQL and MSSQL have different behaviors when inserting a null value into the database. eg.
MySQL will accept the statement and generate a new key. MSSQL will throw an exception.
When inserting subclassed entities quick will retrieve an instance of the parent class and populate (fill) it using
getMemento()
. This causes an issue asgetMemento()
will included empty attributes which will explicity set anid
property with an empty string. This will subsequently flow into thesave()
call causing an exception. UsingretrieveAttributesData()
solved this issue.