Description
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.