After reviewing the Extending Existing Entities documentation, I am wondering if another approach would be to create brand new SQL tables with our new columns rather than taking the approach of altering existing SQL tables. For example, rather than adding Address columns in AbpUsers, could we create a new SQL table called AbpUsersExtention and have that only contain the new Address columns?
Does the AspNetZero team see any issues with this approach? Will this approach create more work for us in the middle and front tier projects? I propose it because we want to make sure upgrading to new versions of Abp is less complicated.
1 Answer(s)
-
0
Yes, that is another approach.
Usually, a good motivation for that approach is if the column is huge and not frequently accessed. The trade-off is that the database will have to perform a join if you want to draw User with Address.
Another motivation may be to avoid Discriminator column when Extending Non-Abstract Entities. Since User implements the abstract AbpUser in the same solution, this does not apply to your case.
Will this approach create more work for us in the middle and front tier projects?
You can handle the join in your domain manager backend. It should not affect your middle (AppService?) and frontend.
I propose it because we want to make sure upgrading to new versions of Abp is less complicated.
There is no need for such pre-emptive measures. User is unlikely to change drastically - even if it does, a migration is likely less work than the implications of the approach you have proposed.
