-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Allow precision 0 in Carbon DBAL types #2537
Allow precision 0 in Carbon DBAL types #2537
Conversation
Sadly, which means this is a breaking change. If an application is currently doing: /**
* @ORM\Column(type="datetime")
*/ without specifying any precision value, they are currently interpreted as I will check the other possibilities. But I would generally advocate for keeping maximum precision for datetimes. You won't regret having precision you don't use, on the opposite side, settle for second-precision at a given moment means the data you're saving now will never have second fraction, and if you need it later, it will be too late for the existing data. Also it's one less thing to bother if have all your datetime/timestamp with constant precision in your DB and don't have to determine which ones will need more or less. |
@kylekatarnls What about an extra argument to explicitly set 0 then? That shouldn't hurt BC |
Indeed, some secondPrecision as a boolean could be a backward compatible solution. |
So in this case, is it enough that I check if there's a key So something like this:
|
@kylekatarnls Could you please confirm if above approach is correct or if I have to supply the flag from somewhere else? Thank you! |
Getting the flag from here would be fine, then as an alternative to nested ternary, the code could be like: $precision = $fieldDeclaration['precision'] ?: 10;
if ($fieldDeclaration['secondPrecision'] ?? false) {
$precision = 0;
}
if ($precision === 10) {
$precision = DateTimeDefaultPrecision::get();
} |
@kylekatarnls Okay, got it, changed it and the tests as well. Could you check it out and if all is good (there's no breaking change or things of sort), run the other workflows (and hopefully at the end, merge the changes)? Thank you! |
Co-authored-by: Kyle <kylekatarnls@users.noreply.github.com>
Allow explicitly defined 0 precision for DBAL types without explicitly setting Datetime precision through
DateTimeDefaultPrecision::set()
because right now explicit 0 precision is treated same asnull
.