⚠️ [ABANDONED] Rinvex Attributable is a robust, intelligent, and integrated Entity-Attribute-Value model (EAV) implementation for Laravel Eloquent, with powerful underlying for managing entity attributes implicitly as relations with ease. It utilizes the power of Laravel Eloquent, with smooth and seamless integration.
Looking at https://github.com/rinvex/attributes/commit/622dfdd2ae8c5a56a45a66612f9e0175f7388df1#diff-ea0d11a7ac5ac10f344772d0863e113d, I'm wondering that if this is considered implementation details, why force the migration of these default types as well? It'd be nice to somehow give the developer an option of opting out of the core type migrations. Would it be better to provide an artisan command to publish (or copy) the core type migration files to the project's database/migration folder instead of loading from the AttributesServiceProvider?
Perhaps we move the core type migration files to the directory .../database/core-type-migrations. This way, the following line of code will only load the necessary tables:
Looking at https://github.com/rinvex/attributes/commit/622dfdd2ae8c5a56a45a66612f9e0175f7388df1#diff-ea0d11a7ac5ac10f344772d0863e113d, I'm wondering that if this is considered implementation details, why force the migration of these default types as well? It'd be nice to somehow give the developer an option of opting out of the core type migrations. Would it be better to provide an artisan command to publish (or copy) the core type migration files to the project's database/migration folder instead of loading from the AttributesServiceProvider?
Perhaps we move the core type migration files to the directory .../database/core-type-migrations. This way, the following line of code will only load the necessary tables:
Then, if the user wants to implement the default core types, they could run
php artisan vendor:publish
orphp artisan rinvex:publish:attributes
.