Set Data.php to support dirty detection on simple data fields

[IronSean]

This PR enables the dirty detection for simple data fields in the DataObject. Use cases would be for any custom event listener or processing on a DataObject Pre-Save event might want to know which fields have been modified to reduce duplicate work.

I however am not positive of the downstream affects this would have or why this was disabled by default. Would this be something that needs other fixes to make sense, or could be controlled with configuration instead?

Changes in this pull request

Resolves #5689

Additional info

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Review Checklist

• Target branch (11.1 for bug fixes, others 11.x)
• Tests (if it's testable code, there should be a test for it - get help)
• Docs (every functionality needs to be documented, see here)
• Migration incl. install.sql (e.g. if the database schema changes, ...)
• Upgrade notes (deprecations, important information, migration hints, ...)
• Label
• Milestone

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[brusch]

To me it seems quite safe to change that.
The only thing I've seen is that we might need some additional work here, as it assumes that only relational data-types are support dirty detection.

pimcore/models/DataObject/Concrete/Dao.php

Line 190 in 130fd27

if ($fd instanceof LazyLoadingSupportInterface && $fd->getLazyLoading()) {

I'll create a PR for that, as I'd classify this as a bug anyway 😉

[brusch]

Just one more thing ... if we set the default to true, we might remove the existing method overrides for supportsDirtyDetection().
Also we need to consider more sophisticated data-types that (might) not be compatible with supportsDirtyDetection(), such as field collections, object bricks, block, calculated value, encrypted field and some more - for them I'd implement supportsDirtyDetection() for them and return false.

Just for reference: this is the PR about the topic before: #16598

[brusch]

Additionally it seems that also the code generation for setters/getters in \Pimcore\Model\DataObject\ClassDefinition\Data need to be optimized, because there's quite some code which wouldn't be necessary for simple data-types in case they support dirty detection, e.g. the following code block:

pimcore/models/DataObject/ClassDefinition/Data.php

Lines 559 to 571 in aac116d

	if ($this->supportsDirtyDetection()) {
	$code .= "\t" . '$hideUnpublished = \\Pimcore\\Model\\DataObject\\Concrete::getHideUnpublished();' . "\n";
	$code .= "\t" . '\\Pimcore\\Model\\DataObject\\Concrete::setHideUnpublished(false);' . "\n";
	if ($class instanceof DataObject\ClassDefinition && $class->getAllowInherit()) {
	$code .= "\t" . '$currentData = \\Pimcore\\Model\\DataObject\\Service::useInheritedValues(false, function() {' . "\n";
	$code .= "\t\t" . 'return $this->get' . ucfirst($this->getName()) . '();' . "\n";
	$code .= "\t" . '});' . "\n";
	} else {
	$code .= "\t" . '$currentData = $this->get' . ucfirst($this->getName()) . '();' . "\n";
	}
	$code .= "\t" . '\\Pimcore\\Model\\DataObject\\Concrete::setHideUnpublished($hideUnpublished);' . "\n";