Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: best practice question: relation between different service Builder enti
Hello together,
I have multiple modules and each module has its own service builder module with some entities. Now I want to create some relations between different service builder entities.
What is best practice for my situation?
Should I create one big service builder module to handle these relations within one service builder module or should I create multiple service builder modules and create relations across them?
If I should use multiple different service builder modules:
I don't know how I create for example a many to many relation to an entity in another service builder module.
How can I create a many to many relation for entities that are across different service builder modules?
best regards
I have multiple modules and each module has its own service builder module with some entities. Now I want to create some relations between different service builder entities.
What is best practice for my situation?
Should I create one big service builder module to handle these relations within one service builder module or should I create multiple service builder modules and create relations across them?
If I should use multiple different service builder modules:
I don't know how I create for example a many to many relation to an entity in another service builder module.
How can I create a many to many relation for entities that are across different service builder modules?
best regards
I would actually want to know how the entities are going to be used by developers...
If a developer or a portlet or a script or whatever is generally only going to use one of the modules and only infrequently use them together, then I'd keep them separate.
If, however, they are typically going to be used at the same time, then they are not really "separate", there is a built in dependency between them. Like a DLFolder and DLFile, for example, you could split those if you wanted, but they clearly have some tight coupling built in such that it makes no sense to split them out.
When you are bridging entities, I would recommend not building in a circular dependency, but one way only. So you build methods and dependencies in A for B-api, but you don't build in any dependencies in B for A-api.
Additionally you want to understand how transactions wrap methods on the SB local interfaces so you know how a transaction will wrap the call and extend the transaction from A down to B calls.
If a developer or a portlet or a script or whatever is generally only going to use one of the modules and only infrequently use them together, then I'd keep them separate.
If, however, they are typically going to be used at the same time, then they are not really "separate", there is a built in dependency between them. Like a DLFolder and DLFile, for example, you could split those if you wanted, but they clearly have some tight coupling built in such that it makes no sense to split them out.
When you are bridging entities, I would recommend not building in a circular dependency, but one way only. So you build methods and dependencies in A for B-api, but you don't build in any dependencies in B for A-api.
Additionally you want to understand how transactions wrap methods on the SB local interfaces so you know how a transaction will wrap the call and extend the transaction from A down to B calls.
Hi David,
Thank you for replying.
I am also interested in the best-pracice regarding a mapping table between two models.
An example for better understanding:
I have a module "todoList" and a module "task" - "task" is also used in some other modules like "calendar" but "todoList" requires some kind of a mapping table to keep track of the tasks in specific todoLists.My understanding so far is, that in servicebuilder I have to include the task entity now into the todoList-servicebuilder-module and create a column in its service.xml with the attribute mapping-table.
I would expect to get a getter getTasks() which gives me List<Tasks> and a getter getTodoLists() which would give me List<TodoList> but in the generated code from service builder there is no getter from this relation column field.
there is only a taskPersistence.setTodoLists(pk, todoLists) and todoListPersistence.setTasks(pk, tasks) am I missing something?
And also is there another way to create a mapping table between "task" and "todoList" while keeping them separated?
thank you in advance.
Thank you for replying.
I am also interested in the best-pracice regarding a mapping table between two models.
An example for better understanding:
I have a module "todoList" and a module "task" - "task" is also used in some other modules like "calendar" but "todoList" requires some kind of a mapping table to keep track of the tasks in specific todoLists.My understanding so far is, that in servicebuilder I have to include the task entity now into the todoList-servicebuilder-module and create a column in its service.xml with the attribute mapping-table.
I would expect to get a getter getTasks() which gives me List<Tasks> and a getter getTodoLists() which would give me List<TodoList> but in the generated code from service builder there is no getter from this relation column field.
there is only a taskPersistence.setTodoLists(pk, todoLists) and todoListPersistence.setTasks(pk, tasks) am I missing something?
And also is there another way to create a mapping table between "task" and "todoList" while keeping them separated?
thank you in advance.
Often times I first want to ensure that I have to have a "many to many" relationship between two entities. In your example, I would actually wonder if a task can be in multiple todo lists; conceptually I wouldn't expect that, and would therefore want to make it a simpler one-to-many and just add the list id in the task entity to keep everything as simple as possible. Whenever possible, discarding a many-to-many relationship or replacing with a simple one-to-many relationship is going to be the easiest path.
When you need a many-to-many relationship, you can use the Liferay mechanism (generated by SB ), or you can roll your own (create your own entity w/ the two fields for the external values, manage CRUD on it yourself). I like the manual option when I'm trying to include more than just the relationship itself, when there is meta information about the relationship (audit info, progress info, etc).
When using the Liferay mechanism, if I have to do something I haven't done before, I'll try to find a corresponding example from the Liferay source to see how they did something. Like the UserGroup and how it handles the users. I figure, if I follow "The Liferay Way", it is a good chance my code won't have issues in the current version or in future upgrades.
When you need a many-to-many relationship, you can use the Liferay mechanism (generated by SB ), or you can roll your own (create your own entity w/ the two fields for the external values, manage CRUD on it yourself). I like the manual option when I'm trying to include more than just the relationship itself, when there is meta information about the relationship (audit info, progress info, etc).
When using the Liferay mechanism, if I have to do something I haven't done before, I'll try to find a corresponding example from the Liferay source to see how they did something. Like the UserGroup and how it handles the users. I figure, if I follow "The Liferay Way", it is a good chance my code won't have issues in the current version or in future upgrades.
Okay I will try to do so. Thank you, that helped me a lot!
best regards
best regards
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™