Fórum

ServiceBuilder: Removal of one-to-many mapping

thumbnail
James Falkner, modificado 11 Anos atrás.

ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 1399 Data de Entrada: 17/09/10 Postagens Recentes
Hi all,

The Liferay Engineering team wants to know: do you use ServiceBuilder's one-to-many mapping feature? If so, you might not realize that it's inefficient in the way it is implemented, and there are better ways to do it, so the team is considering removing it in a future Liferay version. From the developer:

Service Builder's one to many mapping is totally useless.

The reasons are very simple:

1) on the one side, we generate sql like this(Use TrashEntry as example):
SELECT {TrashVersion.*} FROM TrashVersion INNER JOIN TrashEntry ON (TrashEntry.entryId = TrashVersion.entryId) WHERE (TrashEntry.entryId = ?)

This is logically the same as :
SELECT {TrashVersion.*} FROM TrashVersion WHERE (TrashVersion.entryId = ?)

The inner join is totally useless.

At Service layer, the business logic has already eliminated the possibility that we have a "Many side record without the one side counterpart", use TrashEntry as example, that would mean we have a TrashVersion which does not belong to any TrashEntry. If this is actually happening, we must have a broken business logic or fail to rollback the failure transaction, either case we will see more serious problems than an orphan database record showing on the page.

2) on the many side, we already generate a finder to the one side, still use TrashEntry as example, that would be the "EntryId" finder in TrashVersion.
Since we inject all persistence automatically into service, developer can always call the many side finder to do the query which is much more efficient at both the sql level and cache level.



The removal would simply involve removing the mapping-key attribute from the column element in the ServiceBuilder definition. If this does get removed, it will not happen in the 6.1 family of releases. If you are using this, and have an opinion on this feature, let the team know in this thread!
thumbnail
Mika Koivisto, modificado 11 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 1519 Data de Entrada: 07/08/06 Postagens Recentes
I think I'm missing some point but why not fix it instead of removing it? I think it's also currently very confusing to many developers because it doesn't generate accessor methods in the model or the service it just generates the persistence tier. Most developer will expect Hibernate like functionality where you could do trashEntry.getTrashVersions().
thumbnail
James Falkner, modificado 11 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 1399 Data de Entrada: 17/09/10 Postagens Recentes
Mika Koivisto:
I think I'm missing some point but why not fix it instead of removing it?.


Yeah, I was wondering that too. If the current implementation is inefficient, why not just replace it with the "good/simplified" one - and leave the developer service.xml interface as-is? Then there's no developer impact at all. You just get a faster app.
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Yeah, I personally avoid the one to many because just as Mika said if I get the parent object, I can't do a parent.getChildren() sort of call; I have to go back through the XxxLocalServiceUtil class to use a finder to return the list of children.

So the Hibernate/JPA way, the way we all know and love for non Liferay projects, cannot be replicated because of the missing support for the one to many and many to many relationships, which is extremely sad when you know that under the hood, Liferay is delegating the heavy lifting to Hibernate...

Now since I know how the CLP is doing a lot of the magic to get across the class loader boundary, it should be possible to do some sort of proxy injection to handle the one to many and even the many to many relationship resolutions, but it would be a big chunk of code that would probably end up being the source of more errors and/or confusion than we could even imagine (i.e. trying to ensure the collection of children, when modified, would be handled correctly when handed off to hibernate w/ the appropriate cascade option selected by the developer, handling the lazy designation for the one to many correctly, etc.).

Given that most of us have probably already dropped trying to use one to many sorts of mappings and relying on manual collection management via the child's XxxLocalServiceUtil, dropping support for it would probably not affect many real-world users, but as Mika suggested having an actual working solution that those using only the service jar could leverage would be preferable...
thumbnail
Christoph Rabel, modificado 9 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 1554 Data de Entrada: 24/09/09 Postagens Recentes
David H Nebinger:
Yeah, I personally avoid the one to many because just as Mika said if I get the parent object, I can't do a parent.getChildren() sort of call; I have to go back through the XxxLocalServiceUtil class to use a finder to return the list of children.
[...]
Given that most of us have probably already dropped trying to use one to many sorts of mappings and relying on manual collection management via the child's XxxLocalServiceUtil, dropping support for it would probably not many real-world users, but as Mika suggested having an actual working solution that those using only the service jar could leverage would be preferable...


FULL ACK.
Paola Greco, modificado 9 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

New Member Postagens: 7 Data de Entrada: 25/09/13 Postagens Recentes
Dear Friends,

I confess, I am an old style software architect. Weblogic, J2EE and all that kind of paradigmatic wrappers
around common issues and quality requirements grown under a well documented and controlled
process. I don't discuss this kind of social-software and social-architecture based on continuous brain-storming that
you embrace. It's funny I guess, and it produces some results, anyway. But, from my point of view, I have
to finish a job, that is, make a bunch of tiny spiders work together to serve an impression of something smart and useful.
Having to do, daily, with all this brain-storming around so tiny and not so smart spiders, when taken one-by-one, is really
laborious and, I think, not so tightly oriented to productivity. Anyway, that's "progress", isn'it?

I found astonishing that you discuss about one-to-many-relationships for a platform that's on the market
from decades. Astonishing.

So welcome to the shared-brain paradigma, I will try to finish my stupid tiny-spiders platform.

Thank you for your hard job, and your simpaty.
thumbnail
David H Nebinger, modificado 9 Anos atrás.

RE: ServiceBuilder: Removal of one-to-many mapping

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
It's a tough architectural problem to solve, Paola. Liferay is deployed to application servers, and it's the application servers that by design block servlets from crossing the web application class loader boundary (which really was a good thing in the development of app servers and the servlet specs, it just doesn't work well for portlets). This has always been the issue with Liferay (and other portals, btw), and the issue to run it under existing app servers instead of creating a real honest to goodness portal server (seriously, though, who wants to create and support that?).

The hopeful good news is that with Liferay 7 and OSGi, with portlets deployed within the Liferay container, we will no longer have to worry about crossing the web app class loader boundary so this should, finally, give us total access to the underlying Hibernate/JPA tier and therefore the true power of the ORM will be available to the portlets.

Doesn't help much in the short term with your not so smart spiders, but it should give room for hope...