Single Table for comments

Looking at Cuba studio, I don’t see a way for a single table to be able to reference multiple different tables from a single field. Our application looks to be able to have one Comment table to store the comments of many different entities. For example both Table1 and Table2 comments will be stored in the same Comment table. Each comment in the comments table will have a reference for either Table1 or Table2, not both. We are talking about N tables that comments could be associated to. Each of these Entities will be given a Comments tab on each of their Views. My only thought is to add an Attribute of type UUID on the Comment table and program around it. Is this the only option that I have? Is this the suggested approach?

Hi,

i think the keyword for something like this is polymorphic association. Unfortunately JPA (and therefore CUBA) is very limited in that regard.
One solution (as you described) is some kind of soft reference. I suggested a CUBA API for these kind of soft references a few month ago: API for soft references for entities like in "History screen" - CUBA.Platform. You can also find a more detailed description about “polymorphic association” in this discussion.

Nevertheless, there are some downsides on that. But the solution might be suitable for you.

Bye
Mario

1 Like

Hi,

I would recommend using the traditional approach - separate Comments entities for each Table, like T1Comments, T2Comments, etc. They can be inherited from the base Comments entity using JOIN_TABLE or SINGLE_TABLE strategy, depending on the number of Tables and expected number of Comment rows per Table.

This way you will have referential integrity on the database level and no need for additional coding around the reference field.

1 Like

You are right this is also possible, i had never thought about it :slight_smile:

Would that mean that you would place the FKs in the T1Comment class instead of the Comment class? But then, how would it be possible to use SINGLE_TABLE, i would assume that you have to use JOIN_TABLE then, right?

Bye

SINGLE_TABLE will also work, you will just have a “wide” table with one field per reference.

I just wanted to thank you guys for your comments and also let you know of the approach we are taking. We’ve decided to create soft references in the application for our comment table. It would be nice if the application supported polymorphic associations, we are going to have to program around that for now. Hopefully we gain support for that sometime in the future :).

The reason we went with soft references was because the enterprise application we are bringing over is going to have A LOT of tables in it. I’ve identified three tables at this point like the comment table that are secondary tables that will need to be referencing large numbers of tables as well. I know we lose the nice ORM associations and out of the box behavior for having those associations, but we feel we can work around those limitations in these cases. On this scale, we didn’t want to have to work with very wide tables to give us the strong associations. We are going with a more generic approach and will be creating some custom controls and behaviors around these tables as well.

1 Like

Thank you for sharing your ideas. It helps us to prioritize the development tasks.