Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Column type for foreign key field empty when adding ManyToOne relationship with incremental changelogs #15401

Closed
1 task done
marklcg opened this issue Jun 20, 2021 · 11 comments

Comments

@marklcg
Copy link

marklcg commented Jun 20, 2021

Overview of the issue

I have an existing project with multiple entities and incremental changelogs enabled. I'm attempting to add a new entity with unidirectional ManyToOne relationships to the existing entities, however, the generator is not filling in the "type" attribute for the column definition correctly. It is empty resulting in liquibase errors later. In the example case, the type value should be "bigint" but is instead empty ("").

Motivation for or Use Case

I would like to add new entities and with unidirectional relationships to an existing project.

Reproduce the error

This project was generated with jhipster using:

jhipster --incremental-changelog

It's a monolith with default selections and mariadb. I created two entities by importing the following test.jdl (found in the project root).

entity Company {
   companyName String
}

entity Region {
    regionName String
}

To reproduce the issue, add the following to the JDL:

entity Employee {
    firstName String,
    lastName String
}

relationship ManyToOne {
   Employee{region} to Region
   Employee{company} to Company
}

Then re-import:

jhipster import-jdl test.jdl

You will see that the column type is null:

   <changeSet id="20210620155811-1" author="jhipster">
        <createTable tableName="employee">
            <column name="id" type="bigint">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="first_name" type="varchar(255)">
                <constraints nullable="true" />
            </column>
            <column name="last_name" type="varchar(255)">
                <constraints nullable="true" />
            </column>
            <column name="region_id" type=""> <!-- HERE -->
                <constraints nullable="true" />
            </column>
            <column name="company_id" type=""> <!-- HERE -->
                <constraints nullable="true" />
            </column>
            <!-- jhipster-needle-liquibase-add-column - JHipster will add columns here -->
        </createTable>
    </changeSet>
Related issues

N/A

Suggest a Fix

I currently manually set the column types after the import to work around the issue.

JHipster configuration

INFO! Using JHipster version installed locally in current project's node_modules
Welcome to the JHipster Information Sub-Generator

JHipster Version(s)
bug-2@0.0.1-SNAPSHOT /home/xxxx/jhipster/bug2
└── generator-jhipster@7.0.1

JHipster configuration, a .yo-rc.json file generated in the root folder
.yo-rc.json file
{
  "generator-jhipster": {
    "incrementalChangelog": true,
    "blueprints": [],
    "otherModules": [],
    "applicationType": "monolith",
    "baseName": "bug2",
    "jhipsterVersion": "7.0.1",
    "skipClient": false,
    "skipServer": false,
    "skipUserManagement": false,
    "skipCheckLengthOfIdentifier": false,
    "skipFakeData": false,
    "jhiPrefix": "jhi",
    "entitySuffix": "",
    "dtoSuffix": "DTO",
    "testFrameworks": [],
    "pages": [],
    "creationTimestamp": 1624204207376,
    "serviceDiscoveryType": false,
    "reactive": false,
    "authenticationType": "jwt",
    "packageName": "com.example",
    "serverPort": "8080",
    "cacheProvider": "ehcache",
    "enableHibernateCache": true,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mariadb",
    "buildTool": "maven",
    "serverSideOptions": [],
    "websocket": false,
    "searchEngine": false,
    "messageBroker": false,
    "enableSwaggerCodegen": false,
    "clientFramework": "angularX",
    "withAdminUi": true,
    "clientTheme": "none",
    "enableTranslation": false,
    "nativeLanguage": "en",
    "packageFolder": "com/example",
    "jwtSecretKey": "xxxxx",
    "clientPackageManager": "npm",
    "clientThemeVariant": "",
    "languages": ["en", "fr"],
    "entities": ["Company", "Region"],
    "lastLiquibaseTimestamp": 1624204587000
  }
}
JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory
JDL entity definitions
entity Company {
  companyName String
}
entity Region {
  regionName String
}

Environment and Tools

openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.20.10)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.20.10, mixed mode, sharing)

git version 2.27.0
node: v12.18.2
npm: 7.13.0

Docker version 20.10.2, build 20.10.2-0ubuntu1~20.10.1

docker-compose version 1.25.0, build unknown

No change to package.json was detected. No package manager install will be executed.
Congratulations, JHipster execution is complete!

Entity configuration(s) entityName.json files generated in the .jhipster directory

See attached.

Browsers and Operating System

Linux pop-os 5.11.0-7614-generic #15161862669320.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC x86_64 x86_64 x86_64 GNU/Linux

  • Checking this box is mandatory (this is just to show you read everything)
@github-actions
Copy link
Contributor

github-actions bot commented Aug 1, 2021

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 😃.
Comment or this will be closed in 7 days

@egvimo
Copy link
Contributor

egvimo commented Sep 3, 2021

@pascalgrimaud I have the same issue, please reopen.

See my sample app.

@github-actions
Copy link
Contributor

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 😃.
Comment or this will be closed in 7 days

@egvimo
Copy link
Contributor

egvimo commented Oct 30, 2021

Keep it open please.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 1, 2021

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 😃.
Comment or this will be closed in 7 days

@egvimo
Copy link
Contributor

egvimo commented Dec 2, 2021

The issue also persists in 7.4.0.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 2, 2022

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 😃.
Comment or this will be closed in 7 days

@Tcharl
Copy link
Contributor

Tcharl commented Jan 2, 2022

I still don't get the thing about this 'incremental changelog' feature, when we have the liquibase-maven-plugin that is maintained by the liquibase community thus bullet proof...
I would have preferred to get a 'smart' integration of it within the jdl generation process (and of course also integrated with the reactive framework, which is not the case today).

Usage of the liquibase-maven-plugin:

  1. Generate a database with the 'old' version (for example an h2 disk with ddl generated from your main branch)
  2. Modify your entities (i.e. modify your jdl and import it
  3. Execute the ./mvnw liquibase:diff command to get your new changelog
  4. Reference the generated changelog in master.xml

I think that we could wrap this workflow into a import-jdl --incremental-changelog-from-branch=<legacy branch> which would:

  1. Commit everything on the current branch
  2. Switch to the legacy branch
  3. Either startup the test (using h2disk) or start a container with dev database then the tests (IT will populate the database schema)
  4. Switch back to the branch to update (1.)
  5. Launch codegen
  6. ./mvnw compile
  7. ./mvnw liquibase:diff
  8. Add the line in config/liquibase/master.xml
  9. Continue the original jdl generation process.

I know that it would be a little bit painful to implement, but we won't have to maintain our changelog's code anymore (or maybe just the part that updates the .jhipster/*.json in order to keep sources changelog timestamps file and will easily keep being bullet proof on the generated code side.

@mraible
Copy link
Contributor

mraible commented Feb 18, 2022

@Tcharl Should we leave this issue open?

@yelhouti
Copy link
Contributor

yelhouti commented May 12, 2022

@mraible yes please leave it open.

I have been debugging this today and the issue seems to come from:

  1. relationship.otherEntity.liquibaseFakeData

When an entity is added by specifying only and exactly one side:

relationship ManyToOne {
    A{b required} to B
}

NOT

relationship ManyToOne {
    A to B
}

or

relationship ManyToOne {
    A{b required} to B{a}
}

it causes jhipster to not see that B has a new relationship, and not calling prepareFakeData on it, which causes the csv (and depending on the version other stuff) to be broken.

EDIT:
workaround:

generate first with the 2 sides, then regenerate after removing a side if you don't want it

Copy link
Contributor

This issue is stale because it has been open for too long without any activity.
Due to the moving nature of jhipster generated application, bugs can become invalid.
If this issue still applies please comment otherwise it will be closed in 7 days

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 3, 2024
@mraible mraible added this to the 8.7.1 milestone Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants