Kombinierte Ansicht Flache Ansicht Baumansicht
Threads [ Zurück | Nächste ]
toggle
James Falkner
ServiceBuilder: Removal of one-to-many mapping
24. Januar 2013 10:54
Antwort

James Falkner

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1222

Eintrittsdatum: 17. September 2010

Neue Beiträge

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!
Mika Koivisto
RE: ServiceBuilder: Removal of one-to-many mapping
24. Januar 2013 14:38
Antwort

Mika Koivisto

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1501

Eintrittsdatum: 7. August 2006

Neue Beiträge

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().
James Falkner
RE: ServiceBuilder: Removal of one-to-many mapping
24. Januar 2013 16:37
Antwort

James Falkner

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1222

Eintrittsdatum: 17. September 2010

Neue Beiträge

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.
David H Nebinger
RE: ServiceBuilder: Removal of one-to-many mapping
29. Oktober 2014 06:06
Antwort

David H Nebinger

Rang: Liferay Legend

Nachrichten: 7252

Eintrittsdatum: 1. September 2006

Neue Beiträge

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...
Paola Greco
RE: ServiceBuilder: Removal of one-to-many mapping
27. Oktober 2014 09:31
Antwort

Paola Greco

Rang: New Member

Nachrichten: 5

Eintrittsdatum: 25. September 2013

Neue Beiträge

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.
David H Nebinger
RE: ServiceBuilder: Removal of one-to-many mapping
27. Oktober 2014 11:02
Antwort

David H Nebinger

Rang: Liferay Legend

Nachrichten: 7252

Eintrittsdatum: 1. September 2006

Neue Beiträge

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...
Christoph Rabel
RE: ServiceBuilder: Removal of one-to-many mapping
29. Oktober 2014 06:01
Antwort

Christoph Rabel

Rang: Regular Member

Nachrichten: 151

Eintrittsdatum: 24. September 2009

Neue Beiträge

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.