-
Notifications
You must be signed in to change notification settings - Fork 22
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
Error when retrieving and unserialising null DateTime fields #47
Comments
I think what needs to happen is that If you can't get to a PR, let me know and I'll try to take care of it :) |
Hello @jeremyharris ,
which was leading to this error:
So, I had to change the behavior for those as well. This is the final version I've arrived to for the
I'm not sure if I should submit that as a pull request as I'm not a fan of all those IF statements. |
It sounds like we need some tests against DateTime types. If you're comfortable with starting a PR with a failing test for a DateTime column, that might be the way to go. I don't recall if I've personally versioned a DateTime column and I don't see any tests for them, so they might not be supported yet. If you comment calling |
Hello @jeremyharris , |
Hi,
I am using this functionality and I have encountered a bug when I try to retrieve a version of an entry that had a timestamp field with a NULL value.
IE, I have this Model:
When I save it, entries in the news_versions table are correctly created for each field, Since the visible_from and visible_to fields are set as nullable on my DB, they are correctly saved with a value of "N;".
When I retrieve the versions for my News entity by calling
$news->versions()
, I get this error:I have found out that this caused by the
convertFieldsToType
method, called in thegroupVersions
method ofVersionBehavior
.This happens only for Datetime fields, (other nullable fields that are saved as "N;" are being unserialized correctly) and only after updating to CakePHP 4, with version 4.0.1 of this package. This was working fine with CakePHP 3.x, and version 2 of this package.
I have found that commenting the call to
convertFieldsToType
solves the problem (and in fact, this call wasn't present in version 2 of the library), but I'm not sure that that's the most correct way to go, therefore I haven't submitted a pull request.Thanks.
The text was updated successfully, but these errors were encountered: