Liferay Service Builder - is there a recommended way to describe a self reference relation in service.xml? - liferay-7

I want to describe a self reference relation in a Liferay entity. Is there a recommended way to do this ?
I want to do this in order to describe a hierarchy.
At the moment, I just added a new column which I called "parentId" and I will save there the ID of the row that will be the parent of this one. If I use the "Diagram view", from within eclipse, if I draw a self reference relationship it adds a new row that duplicated the name of the ID: for example, suppose I want to describe an employee hierarchy - I have an Employee entity on which I add the default fields; one of these fields is the employeeId field which will be also the primary key. Now, if I draw a self reference relationship, the IDE will add another field entry that will be named the same way (eg. employeeId)

There is no official recommended way to do it, as you will have to add your own logic in your code to handle it.
In case you want to follow the convention used in Liferay code, Liferay code usually represents the hierarchy using a column called parent<primaryKey> and sometimes an auxiliary column called treePath to store the hierarchy path of the element, see:
https://github.com/search?q=repo%3Aliferay%2Fliferay-portal+filename%3Aservice.xml+parent&type=Code
https://github.com/search?q=repo%3Aliferay%2Fliferay-portal+filename%3Aservice.xml+treePath&type=Code
About the treePath column, service builder will add to the java class some methods (buildTreePath and updateTreePath) that will help to populate it, see the service builder templates: https://github.com/liferay/liferay-portal/blob/11e6081f96abb6bf299369519434c1eafa0658e3/modules/util/portal-tools-service-builder/src/main/resources/com/liferay/portal/tools/service/builder/dependencies/extended_model_base_impl.ftl#L65-L115
This column makes easier to get all the parent elements of the hierarchy, just split it by the / char and you will get all the primary keys of the ancestors.

Related

Enterprise Architect: How to change type of element?

I have an element which is created as a table. In the "Element Properties" window, I see the Type is Class and Stereotype is table. For other similar tables, the Type is Table and Stereotype is table. Something seems to be icky with this particular instance.
However, when I run the following script
var element as EA.Element;
element = Repository.GetTreeSelectedObject();
Session.Output(element.Type);
The result is (for both tables!) Class. I thought to outsmart the EA UI by programmatically setting the type, but as both tables (the OK table and the "broken" table) both produce Class when asked for the .Type, I'm hesitant to set the .Type using a script.
I have thought about removing this table and re-adding a new one, but this is tedious as the table has a lot of connections.
How to change the Type of this particular "broken" table to "Table"?
The problem is that both «table» stereotypes are not the same.
The one where the type indicates Table is the correct one.
The other one is a rogue one.
Steps to solve this:
Remove the rogue stereotype from the internal stereotype list Configure | Reference Data | UML Types (to prevent the problem from happening again)
Change the stereotype from the problematic element to the stereotype «table» from the UML profile EAUML. In a script you can do this by setting the property EA.Element.StereotypeEx to the qualified name: EAUML::table). Manually you can use the [...] button to select the correct stereotype from the correct profile.

Combine fields from two tables into one autocompletebox

I have two tables "Services and Projects". Both tables have a "Name" field. I would like to take both fields from both the tables and put them into a single autocompletebox in one of my screens. I searched around and found different methods of doing this but not in LightSwitch. Any ideas?
If I understand your requirement correctly, you want the Name property from both Services and Projects to appear in a single textbox? If this is the case, my approach would be as follows:
Use a view on the data source to union the Projects and Services data sources
Add that view to your data model (on a new data connection)
Define Name as the summary property for the new view-based entity.
Add the view to your screen as a separate query
Add the view data object to your screen as an auto-complete box.
WARNING: You'll also need code-behind to identify whether the value selected is a Project or a Service and to apply this value to the relevant field in your linked entity.

Symfony2: Collection of dropdown select lists for a many-to-many relationship

The objective:
Having a many-to-many relation be displayed as a dynamic list of select inputs(single choice dropdown list)
User arrives on page with a single select field (multiple = false) populated with persisted entities and add/remove buttons. By clicking the add button, a new select field with the same options appears below the first, which adds a new entry in the M2M relation. By clicking remove the field disappears and the entry should be removed.
The model:
Two entities: User & Manager. A User has exactly one "special" Manager and unlimited normal Managers.
Managers manage unlimited users.To model this I have created two relationships for which the user is the "owner" (not sure how to translate this)
ManyToOne specialManager
ManyToMany normalManagers
I haven't created a many to many relationship with attribute "special" because the requirement is exactly one special manager and I wasn't sure if Symfony/Doctrine would cause problems down the line.
What I have:
I can display a multiple select field with the existing entities using Entity field type, as per the documentation. Functionally this is what I need, visually it is not.
I can also use the Collection field type to display a single text field, and add or remove more with JS, as per the documentation. Visually this is what I need, but The text fields (entity attribute) need to be replaced by choice field.
The question:
Before I continue digging, is there a simple way to achieve this list of select tags?
For anyone else who may eventually need a dynamic list of select fields:
I initially solved this issue by detaching the field(s) in event listeners, and handling the display/submission manually in the controller.
However I wasn't satisfied with this clunky solution and when I encountered the same need I used a second solution: creating an intermediary entity xxxChoice (in this case ManagerChoice) which is Mto1 inversed related to User and Mto1 related to Manager. Then by creating a ManagerChoiceType form with "Manager" entity field type I was able to easily display my collection of dropdown select lists.

How do I get the column name from an Entity Framework Association

I have an entity model built using the designer. In one of my tables (application), I have several foreign keys that reference the same status (status) table. As a result, when my associations were built, I have several entity objects built with an auto indexing name:
application_statuses2
application_statuses3
etc.
I'm building a "version history" type screen and want to be able to properly list the "friendly name" for each column modified. For example, I want to display "Destination Status" will be displayed instead of "application_statuses2". If I can determine the endpoint column name on the association in question, I can setup the proper display value.
I can find the entity object in the designer, I can even track where it references the foreign key in question that built the association, but I can seem to find the property that outlines the enpoints or column names. How do I determine the column name, or endpoint, on my association, or entity?
I wish it were more ready to hand, have been looking for it as well. Bit of a pain when you have multiple FKs to the same table.
Click on the navigation property you want to check
Under properties, look at the name of the association
At the top of properties, use the object navigator dropdown to switch to the association
Click into the 'Referential Constraint' property
Use the ellipses button on the right to bring up the column names
Dont know if there is a better way of doing this, but I certainly hope so!

Access the property used in mapping entity to a table in EFv4

When we have two entities in EFv4 EDM diagram and only one table for both in the database (for instance, having table Documents and entities Invoice and Qoute), table Documents having documentTypeId column as a discriminator and set this column as a discriminator in the EDM (in Table mappings), how do we read the value of this property in our code?
We cannot assign values to it because EF does it for us under the hood (based on what we entered in Table mappings for condition) but somehow I don't get it why we are also not allowed to read it.
Imo this property is already mapped so you can't map it again. It is used to determine type of materialized entity. Why do you need such column. Usually it is enough to use is operator like:
var document = context.Documents.GetById(id);
if (document is Invoice)
{
...
}
If you only need to select subtypes you can use OfType extension method like:
var invoices = context.Documents.OfType<Invoice>().ToList();
You also don't need to set this value when adding new entity because you are adding subtype - Invoice or Quote.
Edit:
As I understand from your comment you don't need this information in query. In such case you don't need to map it. Simply use partial class of your entity and add custom property which will return your string. Sound like stupid solution but actually it would be the easiest one.
Discriminator column should be part of mapping metadata so in case of T4 template generating your entities, it could be possible to update the template so it generate such property for you.
You may want to use a single-table inheritance hierarchy, as described here.
That way, you could have an abstract Document class that includes a DocumentTypeId column. Invoices and Quotes would extend this class, but specify certain DocumentTypeId filters. However, because the original class has a DocumentTypeId column, they would each have that column as well.
Another advantage to this approach is that you could create utility methods that can act on any Document, and you could pass any Invoice or Quote to these methods.