You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the problem with EAV structures is that they are not maintained properly. The concrete problem is the following situation:
project enters maturity
new features being added depend on a specific Attribute
there is a fear of changing existing EAV not to break the existing structure
a decision is made for the Attribute to stay in EAV. The complexity accumulates.
The idea is to reduce fear of change by introducing tools that would reduce points of failure in the code.
Detailed Description
There are two tools that can be useful to enable The first one is a dedicated tool to make a migration from EAV to a concrete field on an Entity. In more complicated cases, some method can be overridden in a migration to save all Values in the desired places.
In addition, if that's possible, there could be a way to proxy eav access (by filters and .eav API) to these attributes by a delegate setting on EavConfig.
Context
In a best possible scenario, as an user I would do three steps to refactor EAV Attribute out of EAV system:
Create a new attribute on model.
Create a data migration (automatically) and run it.
Add a delegate setting on EavConfig on a model.
After this, no code is broken and the system uses standard QuerySet/Model API even if it is prefixed by eav in the code.
The text was updated successfully, but these errors were encountered:
Most of the problem with EAV structures is that they are not maintained properly. The concrete problem is the following situation:
The idea is to reduce fear of change by introducing tools that would reduce points of failure in the code.
Detailed Description
There are two tools that can be useful to enable The first one is a dedicated tool to make a migration from EAV to a concrete field on an Entity. In more complicated cases, some method can be overridden in a migration to save all Values in the desired places.
In addition, if that's possible, there could be a way to proxy eav access (by filters and
.eav
API) to these attributes by a delegate setting on EavConfig.Context
In a best possible scenario, as an user I would do three steps to refactor EAV Attribute out of EAV system:
After this, no code is broken and the system uses standard QuerySet/Model API even if it is prefixed by
eav
in the code.The text was updated successfully, but these errors were encountered: