Add versioning to dimension content

[alexander-schranz]

Build on top of: #190

To be discussed:

• Optimize getPublishLocales on write?
• Optimize getLatestVersion on write?
• Versioning an own Interface (make getEffectiveDimensionAttributes and getDefaultDimensionAttributes more complicated is it worse?)
• Is Restore version a workflow transition?
• Should Version be an own Entity / Table extending from other entity? (complexity on overwrite entity (could be validated in compilerpass))

TODO:

• UI Versioning list on settings
• Restore Version

[alexander-schranz]

See whole Graphic

/cc @wachterjohannes not sure if even possible have a transition with the same name with different source and target state?

published     ----restore---> draft
unpublished   ----restore---> unpublished

[wachterjohannes]

Is Restore version a workflow transition?

Answer in my opinion - yes - it should be if possible

if even possible have a transition with the same name with different source and target state?

Yes it is for multiple sources - but as i know only to a single destination. So your example i dont think its possible (maybe with a guard or a listener which sets the destination dynamically by using the further state?)

[coveralls]

Pull Request Test Coverage Report for Build 1298710368

• 155 of 155 (100.0%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 1291214054:	0.0%
Covered Lines:	2059
Relevant Lines:	2059

---

💛 - Coveralls

[wachterjohannes]

am i right when i say the restore itself is not build until now? only the save to a new version during publishing?

[wachterjohannes]

👍 we should optimize this information

[wachterjohannes]

👍 nice solution with the version as attribute

[wachterjohannes]

Optimize getPublishLocales on write?

Yes

Optimize getLatestVersion on write?

Yes

Versioning an own Interface (make getEffectiveDimensionAttributes and getDefaultDimensionAttributes more complicated is it worse?)

Would say no - as long as the implementation of the custom entity wont get to complex (doesnt look like as the moment) at the end this should be a basic and integrated feature for all entities.

Is Restore version a workflow transition?

Already answered in the review above.

Should Version be an own Entity / Table extending from other entity? (complexity on overwrite entity (could be validated in compilerpass))

Would say no - But we should discuss that with @chirimoya because of the problem that the table can get really big (bigger than it is already). But that problem we also have with the current phpcr implementation (at least with doctrine dbal storage)