Ability to define entity options per application

murdos commented 4 years ago

Overview of the feature request

It would be great if it was possible to define entity options inside the definition of an application:

application {
    config {
        baseName firstMS
        applicationType microservice
        databaseType sql
        prodDatabaseType postgresql 
    }
    entities *
    paginate * with pagination
}

application {
    config {
        baseName secondMS
        applicationType microservice
        databaseType sql
        prodDatabaseType mysql 
    }
    entities *
    dto * with mapstruct
    paginate * with infinite-scroll
}

entity A
entity B

Motivation for or Use Case

Use different options per application.

Related issues or PR

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

MathieuAA commented 4 years ago

HI @murdos! Yes, that'd be nice indeed! that way you could really customize what's generated. However, in microservice architectures, you don't usually share entities (and applied options), right? so I wonder: why?

MathieuAA commented 4 years ago

Oh, maybe in gateways/BFFEs... No you're right, this may be needed

Tcharl commented 4 years ago

Hi,

Duplicating entities is a well known microservice pattern: the aggregator service. most of the time you also duplicate backend entities in the gateway in order to avoid the latency induced by sync inter service http calls. You then synchronize them using messaging: when the ms is updated, it sends a message in the queue that updates the gateway 'replica'.

The 'microservice patterns book explains it and you also have plenty of doc on cqrs and CDC which are pushing in that same way.

MathieuAA commented 4 years ago

Yeah I know, just didn't think about these ones. My previous comment reflect that somehow...

MathieuAA commented 4 years ago

I'm gonna POC something. I don't expect too much work, but I can already foresee some possible complications.

MathieuAA commented 4 years ago

An open question to you @jhipster/developers, let's say I have this simplified JDL sample:

application {
  config {
    ...
  }
  entities A, B
  paginate * with pagination // only A & B here
}

entity A
entity B
entity C

paginate * infinite-scroll // A, B & C

What should be the result?

Should A and B be paginated with pagination, and C with infinite-scroll?
Or should all the entities be paginated with infinite-scroll?

In other words which option setting should be taken into account? the global one or the one in the application's scope? I'm leaning towards the one in the application:

it exists in other programming languages (the "shadowing" effect)
everything lives under the application scope in JHipster, and it makes sense to make them the most important "objects" in the JDL

If you agree, vote "+1". Otherwise ~don't vote~ vote "-1" (and I'd love to hear your opinion on the matter!)

deepu105 commented 4 years ago

+1 declaration in the application should take priority

Thanks & Regards, Deepu

On Thu, Mar 26, 2020 at 11:53 PM Mathieu ABOU-AICHI < notifications@github.com> wrote:

An open question to you @jhipster/developers https://github.com/orgs/jhipster/teams/developers, let's say I have this simplified JDL sample:

application { config { ... } entities A, B paginate * with pagination // only A & B here }

entity A entity B entity C

paginate * infinite-scroll // A, B & C

What should be the result?

Should A and B be paginated with pagination, and C with infinite-scroll?

Or should all the entities be paginated with infinite-scroll?

In other words which option setting should be taken into account? the global one or the one in the application's scope? I'm leaning towards the one in the application:

it exists in other programming languages (the "shadowing" effect)

everything lives under the application scope in JHipster, and it makes sense to make them the most important "objects" in the JDL

If you agree, vote "+1". Otherwise don't vote vote "-1"

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/jhipster-core/issues/399#issuecomment-604727941, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKF6PKXJ4SADCOZYNUDLRJPME3ANCNFSM4JJU5N3A .

MathieuAA commented 4 years ago

@deepu105 agreed! that's almost done.

jhipster / jhipster-core