Skip to content

[Live] Fix nullable DateTime hydration with empty value #1901

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

Open
wants to merge 1 commit into
base: 2.x
Choose a base branch
from

Conversation

1ed
Copy link
Contributor

@1ed 1ed commented Jun 9, 2024

Q A
Bug fix? yes
New feature? no
Issues -
License MIT

Currently when we send an empty string as value, the new DateTime('') call
creates an object with the current time, which I think is not correct and the
object should be set to null instead.

@carsonbot carsonbot added Bug Bug Fix Status: Needs Review Needs to be reviewed labels Jun 9, 2024
Copy link
Contributor

@WebMamba WebMamba left a comment

Choose a reason for hiding this comment

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

Yes it sound better for me to have it as null for empty string. Let's wait for what the others thing about it. Thanks for your PR @1ed 😁

Comment on lines +534 to +537
if ('' === $value) {
return $allowsNull ? null : throw new BadRequestHttpException(sprintf('The model path "%s" was sent invalid date data "%s". Setting empty date value is not allowed, send a non-empty value or make the property nullable.', $propertyPathForError, $value, $dateFormat)) ;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

We can't do that this is a BC break. If we want to implement this fix we have to add an option to activate or not your fix and to have it not activate by default.

@smnandre
Copy link
Member

smnandre commented Jun 10, 2024

I'm pretty sure this would have been fixed with the LiveArg implementation we almost sent in 2.18.
At least, it was the same root cause: empty string data handle.

But as we realized it has a minor bug, we had to revert it.

So I'd prefer that we find a more generic way to fix these cases... or i fear every specific type issue will need specific patches, with less coherence and a lot of similar code in various places.

Would you like to have a look at it ?

@smnandre
Copy link
Member

@1ed did you have time to read the other PR i'd be curious to have your opinion...

They may not but they are really due to the same thing
(empty data-attribute or input in HTML sending "" and so interpreted as empty strings in PHP)

Maybe you would have a fresh look / opinion on that matter ?

@jannes-io
Copy link
Contributor

@smnandre instead of reverting #1694 , we could look at implementing this:

Perhaps in the supports method of LiveArgValueResolverTrait we could, after confirming that it's a LiveArg, move the value from _component_action_args to just the attributes but not return any values if the type is expected to be an object. Then the doctrine MapEntity will run, and the value will be where MapEntity expects it to be, and resolves the argument.

@smnandre
Copy link
Member

We had no choice but to revert it, sadly, as it created bugs in rare occasion.

i’m 100% open to any solution :)

@jannes-io
Copy link
Contributor

We had no choice but to revert it, sadly, as it created bugs in rare occasion.

are the bugs documented somewhere or could we add tests that cover current behaviour (other than the ones we already had)? I could take out the bugs but I’d have to be aware of the current situation 😅

@smnandre
Copy link
Member

@jannes-io No, still this problem with Doctrine / other valueresolvers, but this was enough to not release it like that 😅

@Kocal Kocal added Status: Needs Work Additional work is needed and removed Status: Needs Review Needs to be reviewed labels Jun 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Bug Fix LiveComponent Status: Needs Work Additional work is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants