I have one entity class and want to map it to more than one table eg: Comment is entity class and a comment can be on different entities in the system so for entity A comment will be stored in CommentA table for entity B comment will be stored in CommentB table. now I want to map same Comment class with different table through orm.xml and there I can map same class with different tables with different name attribute.
But now how to persist instance of Entity as in persist method it takes only entity class instance and will store it in which table?
the same way how to update?
I want to develop one component which will perform certain CRUD eg: note or comment. Now note can be placed on many entities in a system and I want to maintain them in different tables for each entity. what I want is that I just configure table name in my orm.xml and use same Comment.class as class and specify that name in my service instance of spring configuration and it should do CRUD based on that name.
Which eventually means I am saying when I use instance A of my service which is configured to use name commentsA for Comment entity it will do CRUD on table_a while when I use instance B of my same service which is configured to use name commentB for Comment, it will work on table_b.
You're focused on the name attribute, but have you thought about the foreign key mappings? Each comment relates to a specific entity owning the comment, right? This means if you ever want to find comments for any specific entity, you need a foreign key reference to the owning entity, and each comment type will have a foreign key to a different entity (UserComment points to User, EmployeeComment points to Employee, etc.). All of these foreign keys have to be mapped.
I don't believe there is any way to avoid having separate mappings for each Comment. It would be advisable to use the inheritance mappings and have the Comment class be a superclass of all specific comment classes, but I don't see any way of avoiding separate mappings for each specific Comment entity without significantly rewriting or customizing the ORM code itself.
actually thinking of foreign key would be data centric and I am thinking from componentisation point of view. In actual all the refrential contraints are being managed in database itself, and if I want to fetch entities from reverse direction, I can do it in database and if I know the instance of service I can also configure the correct target entity. Comment is just an example but in real life, cheese is just cheese be it on garlic bread or pizza.
And if we talk about EJB concepts where remoting is possible, lets say CommentsBean is on different server and I am putting comment on my UserBean so I need not to maintain any reference to entity in my User entity and viceversa.
I don't want to design that if I fetch one Entity all the data of my database comes with it. Like if I fetch one user, all the comments are linked with it in entity and all the other work and entities which are associated with that user and then any shared entity where user A worked and user B too, B is also linked through that shared entity path. I mean a user is a user only.
So its like, I want to create one component which can store data in different tables based on configuration. I think it was possible with normal old EJB concepts.
I don't know much about EJBs, but I do know that the ORM layer needs to be aware of the relationships between entities corresponding to the relationships in the database. Managing associations is one of its main advantages.
Relationships in your entities and ORM mappings can be one-directional or bi-directional. No one says that a User object needs to be aware of all its comment objects. The UserComment can have a one-directional reference to the User mirroring the underlying foreign key reference, but the User can be completely unaware of Comments or UserComments. That's one of the reasons why fetching one entity does not bring the whole database with it. Lazy loading is another.
If a comment is just a comment and cheese is just cheese, why do you want to put your comments in different tables? If you don't care where the comment came from, just as you don't care which pizza your cheese ended up on, then just put them in one table. But as soon as you start caring about which pizza got which slice of cheese, or who made what comment, and you start making that differentiation in the database, you need to reflect it in your ORM mappings, or modify the ORM code itself.
CAUTION! Do not touch the blades on your neck propeller while they are active. Tiny ad:
a bit of art, as a gift, the permaculture playing cards