Title: Extending JHipster User
Tags: jhipster
Question: In my system, I have some entities that conceptually inherit from User. For instance, I can have suppliers and regular consumers. I wish to extend the User entity, so that I can inherit all of user benefits like register, login, lost password and so forth.
I though about a few options:
1. Extending the User entity using one of the Hibernate inheritance strategies (https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html), but it looks like a lot of changes in the code is needed. I'd also have to make sure the tables generation would be also correct and working fine with liquibase;
2. Adding all necessary attributes to the User entity and then adding suppliers and consumers as roles. I just don't feel comfortable by doing this since the User table wouldn't be normalized;
3. Creating a relationship from each of these entities to the User entity, but in this case, I don't clearly see how to inherit the user management benefits.
Has anyone ever done something similar so that could shed some light on this?
Thanks in advance.

Here is the accepted answer: I found a way following the second approach.
I added all the attributes for each subclass (in my example, Suppliers and Customers) to the table User (JHI_USER) and a type attribute as well so that I can know which type of user I'm handling. I added also their respective attributes to the User class and updating the related classes, like UserService, UserRepository, test classes and so forth. I used the concept of roles too, but just to provide permissions to each section of the site.
After that, I created an AngularJS state for each user type, passing its type (kinda like a discriminator). For instance, I created a state called /registerSupply passing its type = 'S'. I then edited the original register page to add all the additional suppliers and customer attributes, filtering them out based on the user type and that is it.
As I stated, I don't feel comfortable by using this approach, but in the end, it's basically one of the strategies suggested by Hibernate (https://docs.jboss.org/ejb3/app-server/tutorial/singleinheritance/single.html), which makes me feel a bit better.
Comment for this answer: Hi, If I understood you correctly you didn't extend the User like the link you've mentioned, you changed the user directly. I am looking in how to extend the user at the moment and I am taking the composition approach, the problem is that with this approach(composition) there's a lot of extra work that needs to be done to make it work properly.

Here is another answer: I would rather use composition over inheritance. So basically, you would have Supplier holding a one-to-one relationship with User. This way, you let JHipster User related code unchanged.
User management feature has not yet been released so let's focus on user registration then how would a user qualify as a supplier or customer? Are they supposed to choose by themselves? Can a user be both a consumer and a supplier?
For me the simple JHipster CRUD screens will not be enough, you must be prepared for building your own screens for better UX. So, I would rather focus on having a strong data model and REST API.
Comment for this answer: Which I believe corresponds to my third option. How would these entities take advantage of the user management benefit? The point is that I wanted both suppliers and customers to have a register screen, all login benefits and so on. Do you have anything in mind how I'd accomplish that by using composition? Thanks!
Comment for this answer: Thanks for the clarifications.
Comment for this answer: By the way, answering your question about how the user qualify as a supplier or customer: there will be different registration links. Something like: "Click here to register" linking to the default /register state and in somewhere else in the site there will be another link "I'm a supplier and wish to register", linking to /registerSupplier.
Comment for this answer: I tried to give you more tracks in answer rather than more comments
Comment for this answer: @GaëlMarziou - I am implementing this at the moment but to make this work using composition you still need to change the user adding the reference to your new entity to the user. I am just wondering if the best approach in this case would instead of adding the new fields to user or use composition to use inheritance instead? Any thoughts on that?

Here is another answer: The preferred way explained in this issue is to use Git. Just add your code manually, and use git merge when you regenerate your code from JDL.
Using composition would create a JOIN that has performance impact on a massively used entity. Entity inheritance works but is hard with JPA and would even harder with generated code.
If I had to choose between composition and inheritance, I would prefer here composition with caching when the application grows.

{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 3, 'CommentCount': 0, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2015:00:08/02/15', 'FavoriteCount': None, 'PostTypeId': 1, 'Tags': '<jhipster>', 'Title': 'Extending JHipster User', 'ViewCount': 3064, 'id': 31775243, 'user_AboutMe': '<p>Technical Lead at OSF</p>\n', 'user_AccountId': 4488338.0, 'user_DisplayName': 'Jodevan', 'user_Reputation': 722.0, 'user_Views': 75.0, 'user_id': 3650199.0}}