[Enhancement] Allow customizing of tables

[psychonetic]

Current situation:

It does not matter if you have published the migration files to your usual migrations folder, you can run migrate and you are ready to go. But, if you want to add additional fields to one of those migrations you will have some problems.

• if you publish the migrations and try to modify and run them, the original migrations from package are migrated first. So you end up in an error "table attributes does already exists".
• you can modify the migrations in the package, but this is really dirty.

So the only way for me is at the moment to publish the migrations, modify them as I needed them and delete the migrations of your package. But this is also dirty and if I upgrade to a newer version of your package, I will get a message from composer if I want to discard or accept changes (because I deleted your migrations) and after I need to remove them again and look for changes you may have done.

My question is: Could you force the user to publish the migrations and let him migrate on its own? Actually, this is also how a lot of packages do it and not really a downside for the user.

[Omranic]

Would you give me a real scenario where you need to modify the core migrations please, since I can see it possible to always migrate the core migrations first, and then alter tables the way you want from within your application migrations..

[psychonetic]

I have some additional fields for the attributes table, so the user can create via frontend a new attribute and like Magento, the user can decide how to validate the field, if the field should be unique. This is just an example, but I think there are also other scenarios.

Yes, that would be also a way to go, but in my opinion it's more intuitiv to publish the migrations and edit them after.

But as I said, I just wanted to discuss this solution. I don't know what others may think, but I just know other packages do it in that fashion.

[Omranic]

I still believe the current package architecture is good, and there's nothing limits you from doing so. Your scenario is actually a real case we had, and we already implemented such interface as a solution for users to create attributes and attach it to other entities, and we can't see any limitation even whenever we need to alter database structure. We like to separate architecture layers which in my own opinion is better for separation of concerns and layer isolation, without losing flexibility. You can check that interface package here: rinvex/cortex-attributes in case you're interested in trying it.. 😉 As always, use the dev-develop branch for all untagged packages! ⚠️

[psychonetic]

Okay fine :) Are you interested in a new datatype (decimal)? I would create a pull request in the next days/weeks.

But thank you for your time! I'll take a look at it.

[Omranic]

Yeah sure, please go ahead and add that new data type. PRs are always welcome 🙏