Store metadata information for entities and their attributes in DB

Ideas
#1

Hi,

i have an idea about a feature that i think of might be valuable for different people, so i’d like to share the idea in order to get some feedback if this is a general problem. Lately i saw [PL-8123] and i was thinking about the possibility to store these informations (or annotations on per entity or entityattribute level) in the database and additionally allow CUBA app devs to extend the meta information to their needs
(not only through the Annotations, but through the DB as well).

So when looking at the application properties browser and the mechanism you choosed to either define it in the code (with the config interface and their default values), in app.properties or in the database allows a very high level of flexibility for the app devs to decide where to put the information based upon the desired people that should be able to change it e.g.

With the metadata on the attributes it is actually the same thing. Sometimes it is appropriate to annotate the attributes in the code. But sometimes it is something that should be up to the user (or the administrator) to decide. Here are a couple of examples of that:

  • Default values for entity attributes (this might either be a normal string value, or a reference to a N:1 assication)
  • required attributes for entity attributes (no in the DB but only in the app itself - like it is implemented in the dynamic attributes feature)

But it doesn’t need to be only UI related. Another example would be that in case some entities get imported from other systems, it could be that some attributes should be excluded e.g. So there are plenty of information about an attribute of an entity where it makes sense to not hardcode it into the application code.

I created a sample application that will do the very basic implementation to show the idea.

The definition of a entity metainformation is done through the EntityMetainformation entity. In the customer editor it is used directly by going to the DB and fetching the corresponding value for the desired entity attribute.

I thought of the a real implementation of fetching the config by using the same mechanism as in the Config interface with the additional feature of passing parameters into the interface method:


@Source(type = SourceType.DB)
public interface EntityDefaultValueConfig extends EntityConfig {
    @Property("entity.defaultValue")
    Object getDefaultValue(MetaClass metaClass, MetaProperty metaProperty);
}

Actually, in the platform features there are already some examples where this would be a fit (like the entity logging config e.g.) This mechanism would not only be suitable for Entities and there attributes, but there are some other dimensions as well. One would probably be by screens (& their components).

As i understood the LookupType Annotation is the first step towards a more sophisticated entity meta model and so in this mindset this approach can be seen as well.

What do you think?

Bye
Mario

cuba-example-entity-attribute-metainformation.zip (54.0K)

#2

Hi Mario,

To begin with, I would split the problem into two parts: first is extending the metadata with new properties like default value, etc., and second is to be able to redefine these values at runtime without restarting the server.

I have no doubts about the first part - it should be gradually improved after considering what additional information should be present in the metadata. Let’s discuss it in more detail in this or in a separate thread.

The ability to change metadata in runtime also makes perfect sense, but after some internal discussion we’ve decided that it’s rather a “nice to have” feature and wouldn’t bring much value for our projects. Of course, you may be in a different situation, however I see the following approaches to have some level of flexibility:

  • You can override meta-annotations in metadata.xml and place it in the configuration directory to modify metadata without rebuilding the application.

  • To create a custom mechanism above CUBA metadata as you illustrated in the sample project.

#3

Hi Konstantin,

thanks for the answer.

you are right, these are two distinguished parts.

I have no doubts about the first part - it should be gradually improved after considering what additional information should be present in the metadata. Let’s discuss it in more detail in this or in a separate thread.

So what do you mean by “gradually improved”? Most of the configurations are probably not part of the platform because it is highly application specific. Something like defaultValues might be a platform thing, but if any application decides to use specific icons in the field group or if a particular attribute should be rounded after input value change or some arbitrary other thing - depending on the entity attribute value, this is probably not something that could be baked into the platform.

The second point with the metadata changes at runtime - well it is true, that these changes would not require a tomcat restart, but this is not the reason i brought it up. The reason is quite different. When there is a UI for something like this, it means that it will open up the possibility to configure certain values for the entity attributes to a total different kind of people.

Lets take a default value for a reference entity e.g. In my case, the person that would be capable (Mike Administrator) to understand (and change) the metadata.xml is a system administrator. But this Mike doesn’t have anything to do with the business application. The person that might be capable of deciding what value would be the correct one might be Lisa Key-Account-User. Lisa knows that a particular value might be the right choice in her organisation, but doesn’t have any glue about XML neither has she the rights to go to anything other then https://my-cuba-app.company.com.
Additionally, Lisa might be only able to define this value only for her tenant she is responsible for, but not other tenants…

So basically it doesn’t have anything to do with the tomcat restart, but with a more flexible way of dealing with it, so you might want to rethink the situation?

The idea is inspired by the possibility to configure UIs in Microsoft Dynamics. You might want to have a look at the little youtube video tutorial about it here.

But you might be right, that this is not something that is generally of interested to all platform users. In this case, i might do an application component that will allow such feature. In this case, would it be possible that you guide me towards specific parts of the implementation (especially the configuration interface part)? That would be great.

Bye
Mario

#4

Hi Mario,

By improving the metadata I mean including more useful information in it. And it would be great to discuss and summarize what generic attributes should be defined in the platform. “Required” and “default value” are obvious candidates.

Regarding the second part - a UI for customizing metadata in a deployed application, I think the ability to apply modified values right away is essential here. I just cannot imagine how the process would be organized otherwise - does Lisa Key-Account-User makes changes in the UI and then asks Mike Administrator to restart the server? Maybe it is acceptable for some situations, but generally looks weird.

Our UI for application properties does exactly this - changes are stored in the database and take effect immediately, so I think a metadata UI should do the same. Besides the UI itself it requires creating a database table and specific cache on middleware and clients. The thing I dislike the most is the need to introduce some synchronization into metadata access methods, because metadata become mutable.

Actually I agree with you that such a mechanism would be useful in many cases, and it absolutely does not contradict with our vision of what the platform should be, so I’ll create an issue to consider it in the future. For the time being, would be great if you implemented the feature as you see it in your project or an application component. Of course we are ready to help you in understanding platform internals - just ask. In fact, we often implement and test some features in projects and then generalize and move them to the platform. This way the features become deliberate and with less probability of further need for changes.

#5

:ticket: See the following issue in our bug tracker:

https://youtrack.cuba-platform.com/issue/PL-8743