Studio does not support nested collection container for non-persistent entities

Support
#1

Note, I did not continue this path, so no idea if the framework would actually handle this.

Create 2 non-persistent entities

@MetaClass(name = "octo_CarPart")
public class CarPart extends BaseUuidEntity {
    private static final long serialVersionUID = -8065943679252589538L;
}

@Setter
@Getter
@MetaClass(name = "octo_NewEntity")
public class Car extends BaseUuidEntity {
    private static final long serialVersionUID = 3747792198665284264L;

    @MetaProperty
    protected CarPart steeringWheel;

    @MetaProperty
    protected CarPart wheels;
}

now create a screen and try to create nested datasources.

Selection_089 Selection_090

#2

I’m assuming you want the wheels to be a collection? You’d need to declare them as such. An association or composition is the way to do that…

#3

@jon.craig

crap, that happens when you want to reproduce something with a fictional example and being too fast.
I can no longer update my original post since it is too old (is that new?).

I encountered this using my real model of course. Issue is also there if it is a collection.
Interestingly you cannot even choose composition for non-persistent entities, only association. The GUI is also different it doesn’t contain the multiplicity drop-down but only type of collection.

@MetaClass(name = "octo_NewEntity")
public class Car extends BaseUuidEntity {
    private static final long serialVersionUID = 3747792198665284264L;

    @MetaProperty
    protected CarPart steeringWheel;

    @MetaProperty
    protected List<CarPart> wheels;
}
#5

Thank you for the observation, duly noted.

We may need to reconsider our approach to working with non-persistent entities, especially in the code generation part.

May I ask you why do you need to work with non-persistent entities using CUBA GUI? Do you have a 3rd party data source or interacting with an integration REST API?

#6

@belyaev

I have a few of different usecases, let me give a concrete example.

I am integrating with the msgraph api for creating emails, uploading files to sharepoint, creating attachments, etc…
I don’t want the msgraph api model leaking through my whole application, they contain a whole bunch of information that is irrelevant to my application/users.

So I decoupled them and made some non-persistent entities that just contain the information that i need and the msgraph details are handled in a gateway.

I have for example a createDraftRequest entity containing some basic info such as subject, recipients, body, …

Why did i model this like a non-persistent entity?

  1. To allow to use the databinding mechanism in cuba, so I can create collectioncontainers/instancecontainers and bind forms and tables to them.
  2. I want to be able to quickly switch them to persistent entities if requested by the client. I expected this might happen and for the for some requests we now decided to actually do this.

Important
Following on 1, I thought this was the way to go in Cuba. That it was advisable to use non-persistent entities for communicating data front<->back to allow them to be used with all gui components.

If not, please let me know. What would then be the best approach. What would be the purpose of non-persistent entities in that case?

One of my other tickets is related to this, as I wanted to use the default filtering components on this data.

#7

Hi Tom,

Thank you for such a detailed explanation. It looks like you use non-persistent entities in the correct way. If you will have more questions - don’t hesitate to ask.

Just a bit of advice: please have a look at “Data Components” section in the documentation, to override data loading and data saving (if needed) processes in the GUI properly. I mentioned it in the thread re: filtering, but hope that reminding won’t hurt :slight_smile:

1 Like