Liferay Portal Tools Services Builder

Hello,
using serviceBuilder, it is not possible to define M:N relationship, that uses a mapping table having more columns than just 2 foreign keys...

But there should be an easy way to fix that..

If you define the m-n mapping table in service.xml definition (the way it should be done in serviceBuilder style) and you define the mapping entity extra in service.xml with all the additional attributes, then mapping table entity source code is generated, and all DAO methods in those 2 entities regarding m-n relationship are generated.

there are only two flaws

1. sql DDL script must be modified then to create the mapping table as you want

2. in persistenceImpl of those two m-n entities, all those methods regarding m-n (containsEntity, removeEntity, setEntity etc.) are not influenced by presence of the additional attributes in mapping table, except addEntity, that adds an association between the entity1 and the entity2, because there is

1"INSERT INTO Mapping_table (entity1ID, entity2ID) VALUES (?, ?)"


this would need to be generated different by serviceBuilder, that would have to consider the fact that there are more attributes and generate something like

1"INSERT INTO Mapping_table (entity1ID, entity2ID, myAttribute) VALUES (?, ?, ?)"

Could please anybody take a look at it ? I know that it is not so easy to modify serviceBuilder to change "addEntity()" for this case, because it has consequences, such as 4-5 parent interfaces would change... and then there is the method that adds [an array of entities to one entity] association which wouldn't make sense in this case...

_________________________________



I fully agreed that this would be a very useful improvement. Can you give it a try and create a patch for it?

If you are not familiar with ServiceBuilder's code yet, all the code generated is created from Freemarker templates that can be found in com/liferay/portal/tools/servicebuilder/dependencies/*.ftl. The class that reads the service.xml file (in case you need to extend it) is com.liferay.portal.tools.servicebuilder/ServiceBuilder.java 


___________________________________



I decided to refactor my plugins to not to use service builder after I spend more than day trying to initialize portal+portlet spring context outside container for unit testing and another day trying to write a few tests. It was partially due to maven dependencies, but it is almost impossible if you consider the fact that the plugin should be portable to future releases. As it is impossible to develop complex plugin without full fledged unit testing.

However, regarding the suggestion, I gave it a shot, but it turned out there would be consequences during deployment, upgrading DB etc., it's not that easy as I thought. I have too many dead lines to be engaged with it now.