Task #29543

Clarifiy persistence behavior for inheritance in entities / aggregate roots

Added by Karsten Dambekalns almost 4 years ago. Updated almost 4 years ago.

Status:Resolved Start date:2011-09-07
Priority:Should have Due date:
Assigned To:Karsten Dambekalns % Done:

100%
Category:Persistence
Target version:TYPO3 Flow Base Distribution - 1.0.0
Sprint: Has patch:
PHP Version: Complexity:

Description

For aggregate roots being part of an inheritance chain, how should their repositories behave? Consider this example:

AbstractParty
   +- Person
          +- User

A PersonRepository exists, no UserRepository exists.

  1. Should the PersonRepository also handle User instances?
  2. Should it be possible to switch such behavior on/off?
  3. Or do we require developers to create a repository for every entity in such a chain?
  4. are the above options to be combined?

Related issues

related to TYPO3.Flow - Bug #29416: Aggregate root detection for Person vs AbstractParty is b... Resolved 2011-09-01

Associated revisions

Revision 095a742b
Added by Karsten Dambekalns almost 4 years ago

[TASK] Clarify persistence behavior for inheritance in aggregate roots

This adds a number of functional tests to make sure the repository
behaves as expected. For Person and User, the latter being a subclass
of the former, a PersonRepository will also be able to handle User:

  • it will return both types
  • it will accept both types for add/remove/update

Change-Id: Ic64e8cc7b72fc1f570ab4ed9d09a435707e0cc12
Resolves: #29543

History

#1 Updated by Karsten Dambekalns almost 4 years ago

  • Status changed from Accepted to Needs Feedback

#2 Updated by Christopher Hlubek almost 4 years ago

For me it's necessary that subclasses are handled by a repository. So the PersonRepository would also handle an User. That would also be in sync with OOP concepts. If I specify a type Person, I can also pass a more special Person: an User.

Otherwise one had to create a lot of repository bloat for complex type hierarchies.

#3 Updated by Aske Ertmann almost 4 years ago

I agree with Christopher. I would add that I would expect that if there is a UserRepository present, it would handle the User. Don't know if the configuration to switch the behavior off is necessary.

#4 Updated by Karsten Dambekalns almost 4 years ago

  • Target version changed from 1230 to 1.0.0

As in the given example (Person and User), a PersonRepository will also be able to handle User

  • it will return both types
  • it will accept both types for add/remove/update
  • if more specialized repositories are available, hand over to them
  • handling of sub-types can be switched off (on by default)

#5 Updated by Karsten Dambekalns almost 4 years ago

  • Status changed from Needs Feedback to Accepted

#6 Updated by Karsten Dambekalns almost 4 years ago

A small update to the scope of this:

Karsten Dambekalns wrote:

  • it will return both types
  • it will accept both types for add/remove/update
  • if more specialized repositories are available, hand over to them
  • handling of sub-types can be switched off (on by default)

#7 Updated by Mr. Hudson almost 4 years ago

  • Status changed from Accepted to Under Review

Patch set 1 of change Ic64e8cc7b72fc1f570ab4ed9d09a435707e0cc12 has been pushed to the review server.
It is available at http://review.typo3.org/5455

#8 Updated by Mr. Hudson almost 4 years ago

Patch set 2 of change Ic64e8cc7b72fc1f570ab4ed9d09a435707e0cc12 has been pushed to the review server.
It is available at http://review.typo3.org/5455

#9 Updated by Karsten Dambekalns almost 4 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF