Patch (to be ported)
Project:
Drupal core
Version:
main
Component:
field system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
14 Mar 2025 at 15:15 UTC
Updated:
10 Sep 2026 at 01:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
bbralaAdded the changes from the parent, lets get some working tests.
Comment #5
anjaliprasannan commentedComment #6
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #7
bbralaI did a bugfix for the validator in the parent issue: https://git.drupalcode.org/project/drupal/-/merge_requests/3047/diffs?co...
That change is needed here also.
Comment #8
bbralaComment #9
borisson_I have some small documentation remarks, but this looks great.
Comment #10
bbralaUpdated the comments. :)
Comment #11
bbralaComment #12
smustgrave commentedThis should probably have a CR right?
Comment #13
bbralaYeah cr, is, and title updtae. Since this basically is the implementation of this constraint.
Comment #14
bbralaComment #15
bbralaTitle updated.
I looked at other issues regarding validation, and when there is no change in the interface (like '' becoming NULL) it seems it is not needed to have a CR as far as i can see.
Comment #16
smustgrave commentedRight but maybe we should.
Just to announce the new validation type that contrib modules can now use.
Comment #17
bbralaOk, added a cr
Comment #18
smustgrave commentedAdded to the top of my list for tomorrow!
Comment #19
borisson_I reviewed the CR. It has all the information needed.
Comment #20
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #21
bbralaComment #22
quietone commentedThere are no unanswered questions. I read the MR where I found the comments helpful and clear. And the CR is good to go as well. I updated credit.
Comment #23
larowlanI'm confused about the scope here - the parent issues says
And links to this issue.
But this issue adds the constraint and no tests?
The needs tests tag was added in #3 but then removed later without any discussion I can see (apologies if I've missed something obvious).
We're adding the constraint to the schema too, so should we be adding some tests? Should we be removing something else?
I'm curious about the use of
NULLin the call to->aggregate- it would be good to see some tests confirming that this indeed checks all langcodes for instances where the existing delta is higher.Comment #24
bbralaIn the parent issue there were indeed 2 constraints that needed tests, and since these validation issues have been broken down a lot, i opted to create 2 issues for those contraints. But to test, you need the contraint also so it is implemented here.
Now sure what test you are missing, isnt
NoEntitiesExistYetWithHigherCardinalityTesta test for this contraint? Seems reasonable to test like that. If you recon that is not enough coverage please let me know what you want more.Comment #25
larowlanI don't see any tests for the validator class, only for the constraint
Comment #26
bbralaConfused, the validation runs against the constraint, i try to make cases for the constraint that touch the different paths throuugh the constraint.
Comment #27
smustgrave commented@larowlan thoughts on the last comment?
Comment #28
larowlanI don't see any tests that call ::validate and ensure the constraint validator works
Comment #29
bbralaWow just wow, i think i mixed code because there was indeed no test.
Created a test that validates, and also updated the logic.
delta == count -1, which was not added, so it worked, but only after having 2 extra for the cardinality!
Also rebased.
Comment #30
bbralaNeeds some small fixes in test names and such ot seems.
Comment #31
bbralaDirectory name Contraint vs Constraint. I keep making that typo... ;x
Comment #32
smustgrave commentedAppears feedback around the ::validate is covered in core/modules/field/tests/src/Kernel/Plugin/Validation/Constraint/NoEntitiesExistYetWithHigherCardinalityTest.php now which checks the exception message.
Believe all feedback has been addressed
Comment #34
dcam commentedThe MR for this issue was identified as having a new Kernel/Functional test class that did not have the
#[RunTestsInSeparateProcesses]attribute. A deprecation warning is now issued in the case of these omissions. I've rebased the MR added the attribute to prevent this from being committed as-is and accidentally breaking tests on HEAD. Because this is a minor change to test metadata and the tests are passing I am leaving the issue's status as RTBC.Comment #35
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #36
dcam commentedTests are failing after the rebase with two deprecation errors coming from Symfony:
There is an open issue about the first one: #3555534: Since symfony/validator 7.4: Support for evaluating options in the base Constraint class is deprecated. Initialize properties in the constructor instead..
Comment #38
bbralaThe test is green locally and is unrealted.
I've refactored to the correct pattern since symfony deprecations, should be all good now. Changes were pretty minimal, but had to change tests since there were changes on how to make parameters required which made the test kinda useless.
Comment #39
smustgrave commentedStill LGTM
Comment #40
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #41
dcam commentedPost-bot-rebellion rebase
Comment #42
godotislateSome comments on the MR.
Comment #43
bbralaRebased, upgrades to new symfony and did some cleanup.
All comments are handled.
Comment #44
bbralaOne failure is unrealted. Other failure seems weird, database table doesn't exist. I cannot rerun pipelines right now, so that is fun.
https://git.drupalcode.org/project/drupal/-/pipelines/762176/test_report...
core/tests/Drupal/KernelTests/Core/Field/FieldStorageCreateCheckDeprecationTest.phpSo i guess the exception is real, since it is missing storage. Not sure what is best here, bring back the exception handling? So if we cant query or the query fails have the validation fail? That would end up in this code as a validation error.
Comment #45
bbralaComment #46
bbralaWe actually need the catch for the deprecation test in https://www.drupal.org/node/3475719. I also renamed to NoFieldItemsExistWithHigherCardinality since that is actually true (thanks @joachim in Slack). All is green again.
Comment #47
smustgrave commentedThanks for rebasing seems like OpenTelemetryNodePagePerformance is now failing :(
Comment #48
bbralaFailure is becaude the orde of some id's appearantly changed... Now what? Change the order in the expected?
Comment #49
godotislateI re ran the test. Looks like the failure was intermittent. Is this ready then?
Comment #50
bbralaI do think it is to be honest. But I'm not allowed to do that ;)
(wish we would get rerun priviledges again as subsystem maintainers).
Comment #51
smustgrave commentedRelooked and see new pipeline is green. So weird.. but believe may be good to go.
Comment #52
godotislateOne question on the MR.
Comment #53
dcam commentedI removed that exception handling per #52. The tests are passing. This is ready for another review.
Comment #54
godotislateThanks for the changes @dcam. Ideally we don't want to have @todos without issues to act on them, so it's good that it was resolved.
This is good for RTBC. I think this last change is minor enough for me to commit, but I'll give it a while to see if another committer gets to it first.
Comment #55
borisson_I reviewed this again as well, this has decent test coverage and the validator is looking simple enough to understand what is happening.
rtbc++
Comment #56
godotislateComment #57
godotislateComment #60
godotislateCommitted 20ac0fa and pushed to main. Thanks!
I think there are two things this will need separate 11.x MR for:
#[HasNamedArguments]Attribute to the NoFieldItemsExistWithHigherCardinality constructorComment #61
godotislateI published the CR with 12 as the versions. That will need to be updated with a backport as well.
Comment #62
wim leersWow, a big step forward, and this AFAICT unblocked #3324140: #3324140-64: Convert field_storage_config and field_config's form validation logic to validation constraints 🥳
Comment #64
smustgrave commentedDid 60.1 but for 60.2 what exception should we throw?
Comment #65
smustgrave commentedWanted to follow up if we still wanted to backport or fine with just main?
Comment #66
smustgrave commentedWith D12 alpha out should we just leave there?
Comment #67
godotislateI think we can still try to get this in.
Re #64, the exception handling I was referring to was the one removed from the
maincommit, see comment: https://git.drupalcode.org/project/drupal/-/merge_requests/11481#note_82.... If tests aren't failing on 11.x, then we probably don't need it.