Bug #54057
Recursive validation validates too deep
| Status: | New | Start date: | 2013-11-28 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Extbase | Spent time: | - | |
| Target version: | 7.4 (Backend) | |||
| TYPO3 Version: | 6.2 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | |||
| Complexity: | medium |
Description
Hello Extbase-Team,
I have 2 Domainmodels: Event and Day. It's a MM-Relation. One Event can be at several days and one day there can be several events. Thats why I have defined event.days as LazyObjectStorage and day.events as LazyObjectStorage.
I have debugged the Validator-API and found out that the loop over event.days needs nearly a second.
It validates my event -> days -> all related events incl. my event -> days -> all related events incl. my event -> days -> and so on. Somewhere after many hundreds of loops the validator breaks and returns a valid Result-Object, but all previous validated properties (before days, like: title, eventStart, ...) get lost.
So maybe it would be good to have a cache for already validated objects. They all have a unique identifier spl_hash. So in my opinion it should be possible to implement such a cache.
What do you think about it?
Stefan
Related issues
History
#1 Updated by Markus Klein over 1 year ago
Hm sounds more like an endless loop.
So a cache is more a "side effect", it is more a loop detection mechanism.
Is there any prevention from validation loops at all?
Thinking about A.theB = B; B.theA = A;
#2 Updated by Stefan Froemken over 1 year ago
Hello Markus,
I just found it. There is already a cache inside. The cache is only valid for the current CollectionValidator and not for the whole Domainmodel. Here an example:
Day1:
- Event1
- Event2
- Event3
Day2:
- Event1
- Event3
- Event5
Day3:
- Event1
- Event2
- Event4
So, for each day a new Cache will be created. That means, that Event1 will be validated 3 times. Maybe this works good for 1:1 and 1:N, but not for N:M:
Event1:Day1: Event1
-
---Day1:
---- Event1
-----Day1-3 again
---- Event2
---- Event3
---Day2:
---- Event1
-----Day1-3 again
---- Event3
---- Event5
---Day3:
---- Event1
-----Day1-3 again
---- Event2
---- Event4
-- Event2
-- Event3Day2: Event1
-
---Day1:
---- Event1
-----Day1-3 again
---- Event2
---- Event3
---Day2:
---- Event1
-----Day1-3 again
---- Event3
---- Event5
---Day3:
---- Event1
---- Event2
---- Event4
-- Event3
-- Event5Day3: Event1
-
---Day1:
---- Event1
-----Day1-3 again
---- Event2
---- Event3
---Day2:
---- Event1
---- Event3
---- Event5
---Day3:
---- Event1
---- Event2
---- Event4
-- Event2
-- Event4
Issue #53816 helped me a little bit. Defining event.days as ObjectStorage and day.events as LazyObjectStorage stops recursive endless validation.
What do you think to implement a "stopRecursion"-Annotation for Domainmodel-Properties?
Stefan
#3 Updated by Alexander Schnitzler over 1 year ago
Hi Stefan.
We are aware of these problems as Nico de Haen already spent a lot of time with this issue.
I talked to Anja to have another code sprint just for fixing these validation issues in january.
Most probably we will just join the sprint that takes place with all active contributors. Personally I really struggle with analysing the validation api beside my daily work, so I like the idea of letting this issue rest until we find a weekend to handle this issue together.
#4 Updated by Alexander Opitz 10 months ago
- Project changed from Extbase MVC Framework to Core
- Category changed from Extbase: Validation to Extbase
- Target version changed from 6.2.0 to 7.0
- TYPO3 Version set to 6.2
- Is Regression set to No
#5 Updated by Tymoteusz Motylewski 8 months ago
sounds like related to https://jira.typo3.org/browse/FLOW-17 Persistence: object tree validation performance is really slow
#6 Updated by Mathias Schreiber 7 months ago
- Target version changed from 7.0 to 7.1 (Cleanup)
#7 Updated by Benjamin Mack about 1 month ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)