WIP: Support for readonly on jakarta persistence

[OmarHawk]

Contains changes to more easily extend jakarta persistence configuration in @Column definition

#27048

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[OmarHawk]

Seems like the "IT" tests are not failing, even though they may should in the current state.

I have debugged a sample application using this change and seems like when passing a value in a non-updateable field, the save/saveAndFlush JPA Repository method still returns the set value, even though it is not what is in the (MySQL) database in the end.

I do wonder, how I can actually write a test for this kind of behaviour. Anyone having an idea, maybe @mshima ? Or do you think, we can leave this "sort of" untested this way?

---

According to spring-projects/spring-data-jpa#1735, this is expected behaviour.

[OmarHawk]

By the way, for some reasons, it complains about some Sonar findings - but the only thing I changed there was to extend one test entity. I do wonder, if I need to/should do something about it in this Pull request

[mshima]

New entities added new code and increased complexity, the sonar error is not blocking.

[OmarHawk]

Ok, and any hints regarding testability of these added attributes, if anything that happens in our own generated code won't notice any change due to Spring Data JPA's behaviour?

[mshima]

@OmarHawk readonly is quite uncommon use case.
This looks related to #25414
Use saveAndFlush for jpa and entity with fields that requires flush like @AutoGenerated?

Not sure it’s possible to test a pure @Readonly field.
Maybe another approach is required for created timestamp.
Add a @AutoGenerated which implies @Readonly annotation and test if the returned is not null?

[mshima]

Add readonly to typescript type?

[OmarHawk]

I guess, I may finish this in around 4 weeks - heading off to some vacation. :-)

I think, the very first commit here would already be "worth" integrating, as it does only refactor the template logic for the @Column annotation parameters, but doesn't change anything to the generated applications.
The readonly support may be "extra" then.