JHC - DevXP - Spike - generate entity.json patch instead of erasing the whole json

[Tcharl]

Overview of the feature request

We may be inspired by framework we're using in our generated code, for example liquibase in this particular case. Generating patch (commitid-entityname.json or timestamp-entityname.json) could bring some new cool capabilities to our end users

Motivation for or Use Case

• Only generating the modified fields when combined with needles
• Letting the user to generate his patch (for example adding a jdl annotation on fields) and let him apply a blueprint, a module or an option only for the patched values

What do you think about it?

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

[pascalgrimaud]

Not sure to understand well this ticket. It's probably related to what @mshima has already done with liquibase ?

[Tcharl]

Hi @pascalgrimaud , sorry for not being clear enough, let me take a concrete example so that it will illustrate what I have in mind.

In a first round, the end user will define a simple (sprint 0) jdl entity:

entity Article {
name String
}

Instead of generating an article.json in the .jhipster folder of a project, it would generate a <timetamp>-article.json file with the exact following content:

{
  "name": "Article",
  "action": "add"
  "fields": [
    {
      "fieldName": "title",
      "fieldType": "String",
      "action": "add"
    }]
 }

Then, in a second time, the user will improve his entity model, for example adding a new field:

entity Article {
name String
description String
}

While reimporting, instead of erasing the article.json file, it would generate another <timetamp2>-article.json file containing only the patch compared to the first generation

{
  "name": "Article",
  "action": "modify"
  "fields": [
    {
      "fieldName": "description",
      "fieldType": "String",
      "action": "add"
    }]
 }

Are the benefits expressed in the "motivation" section of the ticket now more clear?

[pascalgrimaud]

Ok I understand the feature, thanks.

Now, my next question is:

• why is it usefull to have :
  • article.json (original)
  • timestamps1-article.json
  • timestamps2-article.json
  • timestamps3-article.json
  • etc ?

It there a specific usecase which is important for having this, for our end-users ?

My workflow on real JHipster projects:

• generate an application with JHipster
• 1st part of entities
  • create a branch
  • add and work on a JDL file
  • import jdl
  • not happy with entities, apply change in JDL
  • import jdl again
  • once it's ok, PR, review, merge into master
• 2nd part of entities
  • create a new branch
  • modify existing JDL file
  • import jdl
  • take care manually of liquibase changelog, to not modify existing ones, but with the recent change from @mshima, this part will be easier
  • once it's ok, PR, review, merge into master

In my workflow, I don't look into entity.json, having 1 or more, doesn't impact my work, but I'd like to understand the value of having xxxx-entity.json ?

[Tcharl]

Let me try to describe the potential value brought by this approach.

I use the exact same workflow as you hopefully, but I'm sometimes struggling with this, here are my pain points:

Sometimes, I added some 'hand crafted' logic on the generated entities. Concrete examples I've currently:

1. added an @Field(type = FieldType.Keyword)on some of my entity's attributes, a @Secured(roleAllowed=...) on some serviceImpl, a specific @Setting on some entities, or even some inheritance on my entities (it's a 3 million-line microservice project, so there are for sure some edge cases).
2. sometimes I do not want entities and only dto (a client serviceImpl calling another microservice Resource endpoint)
3. I also overloaded some Mappers (adding some AfterMapping steps) so I should reference the overloaded versions in my serviceImpl instead of the generated one (otherwise Injection tells me that there are two candidate beans for injection).
4. some angular entity-route.ts file that I tweeked manually, for example modifying for example the 'authorities'
5. And finally, as I'm overload some serviceImpl methods using side-by-side pattern, I have tweaked some Integration test so that they are compatible with my custom business logic.

So usually, I unfortunately do a compare and cherry pick the regenerated changes at your step 2 instead of blindly accepting what jhipster regenerated for me: so loss of time, no really confident to deliver what has been modified and finally a not that enjoyable jhipster experience. However it works and jhipster fill my need: free stack update is a breeze so I'm really happy to be a hipster.

Pro-tip: I found another way process to mitigate that pain points for the second step:

• I modify my jdl
• I use the --json-only flag while generating
• I use the entity generator on every modified entity.json files one by one, to merge, cherry pick and update incrementally.

Now, let see how patches could resolve or mitigate my pain points:

• If needles are protecting my existing fields from an erase, bullets 1, 3 and 5 are resolved by design
• If I create a simple module or blueprint (for example skipping entity generation and throwing a NotImplementedException in my serviceImpl), and can apply it only for a patch, the bullets 2 and 4 are resolved.
• I can even make a blueprint adding my custom annotations on some patches, so that my '@Field' annotations are also generated on some specific fields when I need to :-).

[mshima]

Ok then.

• timestamps*-article.json: I actually do that in the liquibase blueprint but it’s stored inside .yo-rc.json. It’s pretty easy to implement at current state. I kept out for simplicity and not sure how a full reproducible timeline like I did before would be useful.
• needles for fields in entity is possibles for insertions. But what about removals? That would be really difficult.
• IMO you should think about jhipster upgrade approach. Instead of changing jhipster version, change jhipster configuration/entity. This way, you will have a commit that contains every change needed by the changed entity.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days