Generator-jhipster: Make fake data optional

[murdos]

Overview of the issue

The generation and use of fake data should be optional, and should be proposed by prompt, either as a global choice or as a per entity choice.

Motivation for or Use Case

The generator writes data files on the the same place real data are usually put for production (src/main/resources/config/liquibase/data).
There are also open issues with fake data, such as #9579

Suggest a Fix

JHipster Version(s)

6.0.0

[jdubois]

It's already optional, it's a specific Liquibase context, look at the application-dev.yml

[murdos]

It's currently optional at runtime, but I'm suggesting that it be optional during generation.

[pascalgrimaud]

if we changed this to optional at generation, I'd prefer in the additional option section (with Elastic, Kafka, etc), instead of an additional question. But it's just my personal opinion

[murdos]

I've no problem with adding it in the additional option section. I'll update my PR.

[jdubois]

For me this goes against policy 2 by I understand this might be annoying or surprising for many people, so this could be an option.
Then, such options are usually un-checked by default, and I believe this one should be checked by default, which would make a bad UI. So that's quite a lot of trouble...

[pascalgrimaud]

Another solution would be to add a new flag:

• generate data with faker.js by default
• add a new flag --no-faker

I have no real opinion about having it by default or not, as I didn't use it a lot.
But there are some issues which must be fixed first.

[jdubois]

Yes, I think the issues are nearly fixed, we can do a patch release next week

[murdos]

I don't have strong preference for the way to disable it, but I'm convinced that it should be possible to disable it.
It's very common to initialize data for some reference tables in production, and having a mix, or worse, fake data overriding real data each time you regenerate an entity will be really annoying for our users.

[cbornet]

Agree with @jdubois. We already have a runtime option so that seems enough.

[jdubois]

@murdos agreed if you want to have your own "fake data": in that case you must not overwrite the file, so that's one more thing to do when you regenerate, and indeed that's annoying.

Unfortunately I don't have any other solution than removing the fake data totally, and in this case it's already easy to do at runtime -> I'm closing this as I understand we don't all agree, but this has been opened for some time and we need to make a decision at some point.

[murdos]

Just for clarity I don't want to have my own "fake data", I want to have my own real production data, for tables with e.g. referential data, that are loaded in both dev and prod profiles.
And the directory you choose for putting these data (data) is exactly where most people I know are putting their real data, so jhipster fake data will override real data in existing projects and that's what bother me the most.

So the cli option that was proposed in #9663 would have allowed people to control things, and not have jhipster force things.

[murdos]

@jdubois Would you agree to rename the folder containing the fake date files from data to fake-data? I think it would solve the issue.

BTW the content of this folder should probably be excluded from the generated prod package (war, docker image, ...). WDYT?

[jdubois]

Oh you are absolutely right on both points, re-opening!!

[user-0209]

I'm new to JHipster (thanks! great tool!) and I'm trying to create an app with an already existing JDL. That JDL happens to have some one-to-one relationships that lead to the above problem of unique keys, eventually breaking the straight forward way of generating the app and running it. Took me a while to understand what is going on. My two cents on this:

• I want test data, but I need to provide hand crafted data to exercise edge cases. Hence, if you want to provide faked test data, please make it an option. It is definitely better than no tests at all, but of cause has to work.
• Even if there was no faked data, in all the documentation I couldn't find advise on how to provide your own test data. Can documentation on this please be improved as automated testing is good practice.
• And, just in terms of above discussion: I happen to have a one-to-one relationship to the user table. So there is no way of providing ten rows of test data if there are only two users.

[mshima]

Fake data regeneration is really annoying for project regeneration.
I am testing a blueprint and regenerating the project all the time.
Would be really nice an option to don't regenerate the fake data.

A version of skip-fake-data with skip-fake-data-regeneration option:
https://github.com/mshima/generator-jhipster/commits/skip-fake-data-regenerate-option

[pascalgrimaud]

So let's advance on this.
The easier solution which will make everyone happy would be to add simply a new flag: --skip-fakedata
@murdos @mshima : are you ok ? One of you would be ready to work on this ?

[murdos]

Sure! I've a branch/PR that does exactly that. I'll update it

[pascalgrimaud]

Thanks @murdos,
I'm assigning this ticket to you

[mshima]

@pascalgrimaud my changes to @murdos branch is to workaround https://github.com/jhipster/generator-jhipster/issues/10372
Every regeneration changes fake data, making harder to see changes that we are trying to accomplish.

[bigalnz]

How do you still load fake data from the CSV files, but stop faker regenerating new fake data each time you recompile? As I have customised my fake data but it keeps getting overwritten. I am using H2 with disk based persistence.