Changing this makes nullable fields not nullable after the value has been set.

Changing this makes nullable fields not nullable after the value has been set.

That can still be done by calling $user->store(true), as before.

The B/C break, and the PHP-OO break (forward compatibility to PHP 8+) that this fixes would not been addressed without this proposed fix.

The B/C break, and the PHP-OO break (forward compatibility to PHP 8+) that this fixes would not been addressed without this proposed fix.

Undoes a change from #26611

Also, I'm not sure how this is a "PHP-OO break". PHP allows you to change the default value of an optional parameter, it does not enforce optional parameters having the same value as an interface declaration. See https://3v4l.org/vg1Y3 which has run on PHP 7.2.0 through 8.0.0-alpha2. So if you're trying to claim that there is a PHP 8 incompatibility in this case, then that does not exist.

Considering the database schema in core has changed to support null values, the PHP API needs to be similarly adjusted to support these schema updates. In a multi-version compatible extension, you're probably going to need version conditionals to account for the schema changes and the default value of this method's lone parameter is probably correctly changed as a result of the database schema changes.

why is this a B/C break when in a major release ?
what i'm missing from SEMVER

@wilsonge Please check and comment.

I'm afraid that reverting this parameter to false could cause unpredictable effects at this Beta 3 stage. Probably it would be better to adapt extensions to the new behavior.

why is this a B/C break when in a major release ?

Hi @alikon , Because there is no depreciation notice.

Hi @mbabker , Thanks for the detailed reply and reference to the PR #26611, better understanding the reasoning behind the breaking change now. Yes, I am already adding many version conditionals, for most of them, I'm not signaling them, as they were, kudos to Joomla devs ? , preceded by a deprecation notices with only few exceptions (e.g. DatabaseDriver::getLogs() got removed without prior deprecation notice, but it's perfectly ok, as it's a seldom-used debug feature). But this one was changed without deprecation, and is a breaking change, potentially affecting many extensions, that use the overlaying User::save(), that doesn't have the updateNulls parameter. I can adapt CB's middle-layer for that, no worries, but I do care about Joomla developers-friendliness for other extensions-developers and their users, and this one might be a pesky B/C non-compatibility to debug for some extensions. That's why I have raised a heads-up and a PR proposal.

But I now do better understand the reasons for this change, and am hesitating if it's a good change or not, as it's inconsistent with all/most other database usages, and inconsistent with its Interface specification (even though PHP allows it up to now, and looks like in 8.0-alpha too, it's probably not best OOP practice). At very least, the TableInterface @param description should imho be updated that updateNulls is not by default=false for all TableInterface classes (with a @since 4.0 remark).

I have tested this item ✅ successfully on abc0117

It is working from frontend and backend

I have tested this item ✅ successfully on abc0117

Working as expected

@wilsonge I think we need as decision here.

Setting "Discussion" status since there are reasons against merging this pull request, see the above comments.

I have implemented a workaround by checking Joomla version in CB, so the multi-joomla-versions version of CB in preparation is running fine on both Joomla 3 and 4. So this is not a J4 show-stopper as far as I am concerned. It was more a B/C issue. But I guess very few extensions use that method, so not a big B/C issue either.

The minimum, cool thing, would be to at least document the incompatibility in J4 and depracation in J3. And maybe to update the TableInterface $updateNull parameter description ? (or even default value?)

So as far as I am concerned, we can close this PR, or use it for non-release-blocking discussion.

@beat Well you could close it yourself and make an issue for the documentation.

The minimum, cool thing, would be to at least document the incompatibility in J4 and depracation in J3.

@beat The zero date deprecation is mentioned in section "Updated System Requirements", sub-section "PHP MySQL Extension" here: https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4 .

In section "About The Database Changes of https://docs.joomla.org/Version_4.0_Beta_FAQ , you find more detailed information about the change from zero dates to null dates.

I'm closing this one here with respect to all previous comments.