Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed issue with NULL values being inserted into identity columns for MSSQL #250

Merged
merged 3 commits into from
Jun 12, 2024

Conversation

ryanalbrecht
Copy link
Contributor

In relation to auto-incrementing fields MySQL and MSSQL have different behaviors when inserting a null value into the database. eg.

# id = auto-increment
INSERT INTO song (id,title) 
VALUES (NULL, 'some song name')

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 as getMemento() will included empty attributes which will explicity set an id property with an empty string. This will subsequently flow into the save() call causing an exception. Using retrieveAttributesData() solved this issue.

@elpete
Copy link
Collaborator

elpete commented Jun 11, 2024

Looks like you have some failures on Adobe engines to check.

@ryanalbrecht
Copy link
Contributor Author

@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?

@elpete
Copy link
Collaborator

elpete commented Jun 12, 2024

I think we do this in two parts:

  1. Update the migration that creates this column to create it at the correct precision level. The raw function should let you do that.
  2. Add a ticket in qb to consider changing the default MySQL timestamp and datetime columns to have millisecond precision.

@ryanalbrecht
Copy link
Contributor Author

Copy that. Will get to work on this

-fix attribute hash test by precomputing hash
-fix issue with comparison test by specifying timestamp precision on table song migration
@ryanalbrecht
Copy link
Contributor Author

I changed the migration for the 'songs' table to be created using the raw function. I also added changes for qb.

See pr coldbox-modules/qb#282

@elpete elpete merged commit 4ae80fa into coldbox-modules:main Jun 12, 2024
14 checks passed
@elpete
Copy link
Collaborator

elpete commented Jun 12, 2024

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants