Foren

Service builder - Foreign key - does it really work?

thumbnail
Sơn Tuấn Nguyễn, geändert vor 11 Jahren.

Service builder - Foreign key - does it really work?

Junior Member Beiträge: 37 Beitrittsdatum: 02.03.10 Neueste Beiträge
As i've developed for months now with MCV Portlet, service builder is cool.
And I know how to use foreign key like this:

<column name="locationId" type="Collection" entity="Location" mapping-key="id" />
<column name="locationId" type="String" />

However, yesterday I encountered a case that I could insert a record with locationId doesn't exist in parent table Location.

So the FK referenced in service.xml only helps if you update data in parent table, it will update data in child table.
And it doesn't check if inserted data in child table should exist in parent table, does it?

If this is true, we have to manually check for valid data right ?

Thanks in advance
thumbnail
Hitesh Methani, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Regular Member Beiträge: 171 Beitrittsdatum: 24.06.10 Neueste Beiträge
Hello Sơn Tuấn Nguyễn,

Even we encountered the same problem.
Think you need to have a manual check in that case.

Regards,
Hitesh
thumbnail
Hitoshi Ozawa, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 7942 Beitrittsdatum: 24.03.10 Neueste Beiträge
If you check the database, there really isn't any FK created. service.xml just defines specifies "relationships". If you studied service modelling in service oriented architecture, this is how it is suppose to be to make service autonomous.
Dimitrios Zigkos, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

New Member Beiträge: 6 Beitrittsdatum: 19.10.12 Neueste Beiträge
Hello Hitoshi and all,
I try to handle the one-to-many relationship in Liferay. one of my problems is that there are no setters for the Collections in the case of FK. I look up the [Entity]PersistenceImpl.class service builder creates, and I find lists of queries that refer to FKs. But those queries throw ERRORS when I run the portlet!

Lets say that we have the following entities in the service.xml (A persons has many jobs to do):
<entity name="Person" table="Person" local-service="true" remote-service="false">
<column name="personID" type="long" primary="true" />
<column name="firstName" type="String" />
<column name="lastName" type="String" />
<column name="jobs" type="Collection" entity="Job" mapping-key="jobID" />
...
</entity>
<entity name="Job" table="Job" local-service="true" remote-service="false">
<column name="jobID" type="long" primary="true" />
<column name="title" type="String" />
<column name="description" type="String" />
...
</entity>

Am I correct to consider that inside PersonLocalServiceImpl.java I can call the PersonUtil.getJobs(personID) for getting the List<Jobs> --(getter)?
If yes, how can I set the collection I have prepared elsewhere into this Person instance --(setter)?

Please assist...
Thank you,
Dimitrios Zigkos
thumbnail
David H Nebinger, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 14916 Beitrittsdatum: 02.09.06 Neueste Beiträge
Liferay's Service Builder does not support 1-many or fkey relationships.

It is up to you to implement this.
Asmaa Ismail, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

New Member Beiträge: 10 Beitrittsdatum: 22.09.12 Neueste Beiträge
I have a related Question here..
If I've a parent child case
Do I have to insert the parent alone and then loop on the child list and insert each object individually ??
Or how can I make the parent object persists its children with it??
Thanks in Advance,
Best Regards,
Asmaa
thumbnail
David H Nebinger, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 14916 Beitrittsdatum: 02.09.06 Neueste Beiträge
You persist them all (parent and children) individually.
thumbnail
Jack Bakker, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Master Beiträge: 978 Beitrittsdatum: 03.01.10 Neueste Beiträge
how do u manage transactions and rollback David ?
thumbnail
David H Nebinger, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 14916 Beitrittsdatum: 02.09.06 Neueste Beiträge
A transaction will be automatically wrapped around every service builder method that starts with add, update, delete (and I believe create and some others, but don't have a list handy).

To bind all of these into a single transaction, the key is to create one entry point in your XxxLocalServiceImpl class to handle the bulk insert/update:

public Parent addParentAndChildren(final Parent parent, final List<child> children) {
  // persist the parent object the way you normally would

  // handle the children here, whether you do a simple case of deleting the current children and blindly adding the children in the list
  // or a more complex method of selectively adding, removing, and updating children as given in the list.

  // return the parent instance, this is standard for all add/update operations of Service Builder
  return parent;
}</child>


Now when you call ParentLocalServiceUtil.addParentAndChildren(myParent, myChildren), this will all be handled within the scope of a single transaction.

So my original statement of "parent and children must be inserted manually" is still true, it is still up to the developer to manage the inserts.
thumbnail
Jack Bakker, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Master Beiträge: 978 Beitrittsdatum: 03.01.10 Neueste Beiträge
David, inside your addParentAndChildren, could you safely call other XxxLocalServiceUtil.add(Xxx xxx) or better to use xxxPersistence methods to do your add, update, delete
thumbnail
David H Nebinger, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 14916 Beitrittsdatum: 02.09.06 Neueste Beiträge
You can safely call either. Since the transaction is already open, a new transaction will not be created for the internal calls. Transactions just get created when there is not already one in play...
thumbnail
Jack Bakker, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Master Beiträge: 978 Beitrittsdatum: 03.01.10 Neueste Beiträge
David H Nebinger:
You can safely call either. Since the transaction is already open, a new transaction will not be created for the internal calls. Transactions just get created when there is not already one in play...


Thanks David ; does this hold true across multiple service.xml with different tx-manager ?

I still have to dig into the belly of this stuff ; hoping u have more experience
thumbnail
David H Nebinger, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Legend Beiträge: 14916 Beitrittsdatum: 02.09.06 Neueste Beiträge
It should. The txn is created for the first method and the others where a txn would have been created (via AOP) will see there is already an open transaction and not create a new one...
thumbnail
Jack Bakker, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

Liferay Master Beiträge: 978 Beitrittsdatum: 03.01.10 Neueste Beiträge
Thanks David
Dimitrios Zigkos, geändert vor 11 Jahren.

RE: Service builder - Foreign key - does it really work?

New Member Beiträge: 6 Beitrittsdatum: 19.10.12 Neueste Beiträge
I've finally resolved the problem with the FK.
I had to change the Collection of the Person entity as follows:
<column name="jobs" type="Collection" entity="Job" mapping-key="personID" />
and in the Job entity to insert a new column:
<column name="personID" type="long" />

This will allow the invocation of both:
PersonUtil.getJobs(personID)
PersonUtil.setJobs(List<Job>)

So, without the declaration of a FK, Liferay handles implicitly the personID coloumn of Job as a real FK.
It will justify the existence of that column in the queries in the class PersonPersistenceImpl.

I hope this helps.
Thank you all for the contribution.