Skip to content

Conversation

alexandre-abrioux
Copy link
Contributor

This small PR fixes a minor regression that I think was introduced in 55df57f.

Issue

When updating an entity and changing a date property to another one very close to it (by a difference in microseconds), the change is not persisted in the database. Indeed, diffing dates by comparing the toString() output doesn't give enough precision to compare microseconds shifts. Example:

  • toString() output: Tue Oct 01 2024 08:54:48 GMT+0000 (Coordinated Universal Time)
  • toISOString() output: 2024-10-01T08:54:48.651Z

Two dates can have the same toString() output even though their toISOString() output is different.

The impact is low and probably only concerns the test scenarios: It's rare to persist the same entity twice in the same second without changing anything other than a date.

Fix

In this PR I'm switching the dates comparison to use toISOString() and adding a new unit test.

@alexandre-abrioux alexandre-abrioux changed the title fix: diff dates by microseconds fix(core): diff dates by microseconds Oct 1, 2024
@alexandre-abrioux alexandre-abrioux changed the title fix(core): diff dates by microseconds fix(core): fix same-second dates diffing Oct 1, 2024
@alexandre-abrioux
Copy link
Contributor Author

I reverted the test changes made in 55df57f, the CI should pass now

Comment on lines +64 to +65
healthcheck:
test: /opt/mssql-tools/bin/sqlcmd -S mssql -U sa -P 'Root.Root' -Q 'select 1'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@boenrobot looks like this solves the flaky CI runs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm or maybe not :D but it feels better, lets see

Copy link
Collaborator

@boenrobot boenrobot Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, spoke too soon, judging by the latest commit results in master. But I'm sure this does help reduce the flaky-ness.

Copy link

codecov bot commented Oct 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.79%. Comparing base (8ba8d7a) to head (441eeab).
Report is 3 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #6094   +/-   ##
=======================================
  Coverage   99.79%   99.79%           
=======================================
  Files         264      264           
  Lines       18756    18757    +1     
  Branches     4090     4090           
=======================================
+ Hits        18717    18718    +1     
  Misses         39       39           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@B4nan B4nan merged commit cd7ce82 into mikro-orm:master Oct 1, 2024
12 checks passed
@alexandre-abrioux alexandre-abrioux deleted the compare-dates branch October 1, 2024 10:37
B4nan pushed a commit that referenced this pull request Oct 7, 2024
This PR fixes an issue I introduced in
#6094

Using `toISOString()` on an invalid date throws a [RangeError
exception](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString#exceptions).
We should test if the date is valid before comparing it with
`toISOString()`.
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.

3 participants