Immutable datetimes on timestampable #7795
Conversation
2c08acd to
707f59b
Compare
|
Looks like there are a lot of places that use the |
|
@mamazu which API entity use the Interface? Most shouldn't as they should be API specific and not extend that interface. The Entities itself should be able to remove current method in the interface as the timestampableinterface already defines the method signature. |
|
The problem is not the interface its the usage of the trait. Like for example the |
c29a97d to
ff02f50
Compare
|
@alexander-schranz i have rebased the branch, changed the Interface to use \DateTimeImmutable and added a section to the UPGRADE |
|
This (#7797) would be a pre-requite for this branch anyways. |
ca77641 to
baa840a
Compare
44d0934 to
66ef1ed
Compare
66ef1ed to
d931ae7
Compare
| > [!WARNING] | ||
| > You need to generate a migration for your own project, since this also effects custom entities in your project. For | ||
| the Sulu base see migrations below. |
There was a problem hiding this comment.
@wachterjohannes This doesn't only affect the migration in the database. This also means that people need to modify the trash handler for the entity. Maybe we could also handle this in a more general fashion.
What's in this PR?
Replacing the changed and updated fields to contain immutable datetime objects (see issue).
The interface is now strictly types to only accept
DatetimeImmutableas input and returnDateTimeInterfaceas output.Why?
Technically the created at and updated add should only ever represent "now" and should never be modified.