Readonly entity fields in jdl

[M4jor-Tom]

Overview of the feature request

Something like that would be interesting:

entity Object {  density Double required  volume Double required  mass Double readonly as density * volume //Creates a getter with readonly frontend/CRUD support  eligibleFoo Foo readonly as null //Same as before, returning just null so we can set watever we want }

*The entity Object is NOT readOnly

Motivation for or Use Case

At work, I use a lot of calculating and/or reference chaining getters because my client wants a summarisation/concatenisation/aggregation on its screens.

This can be useful for: -Calculation; -ObjectKind data in Object other than otherField. -Post Service process data injection in domain objects.

Related issues or PR

https://github.com/jhipster/generator-jhipster/issues/8800 https://github.com/jhipster/jhipster-core/issues/318

• [x] Checking this box is mandatory (this is just to show you read everything)

[mshima]

At angular you can use @Readonly annotation. Not sure about react or vue.

[M4jor-Tom]

Is that annotation to be set in the JDL ?

[mshima]

Yes.

entity Foo {
  @Readonly name String
}

[M4jor-Tom]

Thanks for help, I thought it didn't exist, sorry for the fake issue, it works for React, as well (didn't try full execution, but could see that Foo.json would specify "readonly": true)

[mshima]

We lack documentation for annotations and customizations. Hopefully we can improve it soon.

[M4jor-Tom]

Yes, I've got another idea but I'm not sure I should open an feature issue for that reason, what do you think if we could use a several-crossed-relationships otherfield ?

For example, we have those entities: User{login} <OneToOne> UserData{foo} <OneToMany> Post{content}, and we'd like to show User.login in Post through UserData's relations. We'd have that:

relationship OneToMany {  UserData to Post{userData(user.login)} }

Do you think it's worth issuing or does such a thing already exist ?

[M4jor-Tom]

Yes.

entity Foo {
  @Readonly name String
}

Back to that, I tried it, but ommiting Foo.name is readonly: true in Foo.json, nothing seems to change otherwise. Indeed, I was able to set a @Readonly field and its new value persisted.

Is there something I am still missing ?

[mshima]

Do you think it's worth issuing or does such a thing already exist ?

This feature looks quite specific. Not sure it’s appropriate to have it implemented.

Back to that, I tried it, but ommiting Foo.name is readonly: true in Foo.json, nothing seems to change otherwise. Indeed, I was able to set a @readonly field and its new value persisted.

Is there something I am still missing ?

Readonly support is quite specific, supported by angular for id fields. You may be better luck to use mapstruct: https://github.com/jhipster/generator-jhipster/blob/c6f390468c156a602e7603bd976eadd93151bff1/test-integration/samples/jdl-entities/entities.jdl#L7

Those features are related to the unmerged composite id support.

[M4jor-Tom]

What I anderstood about all that, as a mostly a React and Vue and non-expert programmer, after reading https://www.pluralsight.com/guides/rendering-read-only-data-with-angular to anderstand what @Readonly should make with angular, is that Angular should disable Update and Delete functionnalities from user interface, so we could still Create, and Read what's been generated whatever acts in backend.

In our case, (JHipster), it seems like an Angular @Readonly is like a WORM (Write Once Read Many) field, like JPA's id.

What I'd like to do is even to have an on-read-generated transient field, like calculus or string confluence.

Your commit seems to do the job, even if I'm not sure of what it's about, but my implementation of what I'd need at work doesn't required a MapStruct or a DTO.

Am I wrong not doing so ? Am I misunderstanding ?

[drissslim]

Any idea on the described use case and how to reference user.login in subsequent entity related to a UserData entity?

[M4jor-Tom]

Conceptually: To me, chaining an additional entity in the relationship's other field's name as it follows (with defined entity, of course):

relationship OneToMany {  UserData to Post{userData(user.login)} }

Suffises, because it is possible to know from that, that: -"Post" entity must own a "userData" field -"UserData" entity must own a "user" field -Of course, "User" entity natively owns a login field, but it will have to be specified in the same way for a developer-created entity such as others. -> Event better, why not would we be able to define longer references chains for other fields' names ? We could have:

relationship OneToMany {  Forum to Topic{firstPost(userData.user.login)} }

Technically: As for normal and existing other field mechanism, we don't need specific getters in domain layer, just reference chaining in frontend, this should be enough with null references checking.

[DanielFran]

Closing, fixed in V8