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: What is the right way of implementing simple User-entity link in CE 7.x
Hi!
There is a simple CustomEntity in project. The entity is Asset-enabled. It's necessary to link the CustomEntity with Liferay User entity to create a User's wishlist.
Technically, it's a many-to-many relationship table between CustomEntity and User. Would be great if i can describe the relationship in services.xml like following:
The idea of adding as little as a many-to-many table and couple of methods to CustomEntityService to lookup CustomEntities by User / User.id looks attractive. Would be great to utilize the system as much as possible. Is there a way to do this?
Alternatively, if none, can i avoid creating service(s) for wishlist and overbloating the many-to-many table with Status / Audit fields, finders, references, etc? How to implement it in the most simple and lighweight way?
Thanks,
Dmitriy
There is a simple CustomEntity in project. The entity is Asset-enabled. It's necessary to link the CustomEntity with Liferay User entity to create a User's wishlist.
Technically, it's a many-to-many relationship table between CustomEntity and User. Would be great if i can describe the relationship in services.xml like following:
<entity name="CustomEntity" local-service="true" remote-service="false" cache-enabled="false">
<column name="id" type="long" primary="true" />
<column name="wishedBy" type="Collection" entity="com.liferay.portal.kernel.model.User" mapping-table="User2CustomEntityWishList" />
</entity>
... but Service builder generates CustomEntityLocalServiceBaseImpl code expecting related methods(addCustomEntity(), removeCustomEntity(), etc.) in com.liferay.portal.kernel.service.persistence.UserPersistence class. The code, of cource, is not compilable.The idea of adding as little as a many-to-many table and couple of methods to CustomEntityService to lookup CustomEntities by User / User.id looks attractive. Would be great to utilize the system as much as possible. Is there a way to do this?
Alternatively, if none, can i avoid creating service(s) for wishlist and overbloating the many-to-many table with Status / Audit fields, finders, references, etc? How to implement it in the most simple and lighweight way?
Thanks,
Dmitriy
Hi Dimitriy,
I'm not entirely sure I am following but let's see. From what I understand you (of course) have a User table (Liferay provided as we all know) and then you have a WishList table which you have defined in service builder. And now you want to link the two -- and if I am understanding you correctly, I think the simplest answer is to have a
User_WishList
mapping table (service builder entity). You can include just the userId and the wishListId to limit the number of columns, but I would only do that if I knew my Liferay install would only ever have one portal instance and one site. I understand that you wuld rather have 1000 users all wishing for the same item to be stored in a single row, but a you can see that's not as easy. The userId/wishListId would be unique though so you could define a finder in which case the looks ups would be super fast.
You seem to be concerned about the potential size of the data (number of records) -- are you expecting a huge volume?
I'm not entirely sure I am following but let's see. From what I understand you (of course) have a User table (Liferay provided as we all know) and then you have a WishList table which you have defined in service builder. And now you want to link the two -- and if I am understanding you correctly, I think the simplest answer is to have a
User_WishList
mapping table (service builder entity). You can include just the userId and the wishListId to limit the number of columns, but I would only do that if I knew my Liferay install would only ever have one portal instance and one site. I understand that you wuld rather have 1000 users all wishing for the same item to be stored in a single row, but a you can see that's not as easy. The userId/wishListId would be unique though so you could define a finder in which case the looks ups would be super fast.
You seem to be concerned about the potential size of the data (number of records) -- are you expecting a huge volume?
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™