Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## 4.0 #216 +/- ##
============================================
- Coverage 65.22% 64.88% -0.34%
- Complexity 363 367 +4
============================================
Files 49 50 +1
Lines 1734 1743 +9
============================================
Hits 1131 1131
- Misses 603 612 +9 ☔ View full report in Codecov by Sentry. |
alexmerlin
left a comment
There was a problem hiding this comment.
This seems to be a mixture of the two solutions (2.1 and 2.2) that I recommended.
The point of 2.2 is to have a single EnumType class that can be reused across all entities.
My recommendations:
- create a new directory inside
src/App/src, call itDoctrineorTypes - refactor
src/Admin/src/Entity/EnumAdminStatus.phpby moving it to that new directory and calling itEnumType - register
EnumTypeinsideconfig/autoload/doctrine.global.phpas before - adapt
Adminentity by setting thestatusproperty's type toEnumType::NAME
Note:
Once you run the migration and the fixture, executing the diff command will throw an error, complaining that in EnumType::getSQLDeclaration the key values does not exist (neither would default, but that's a coincidence that it exists in both the type definition and the database table). This happens because executing the diff command will compare the already existing status column with the definition found in the entity. It is the definition coming from the database that does not have the values key.
You need to dig further in order to find out how to fix this issue.
|
Let's keep this open until we decide what to do with it |
|
Closing in favor of #300 |
#212 2.2