Generator-jhipster: PersistentAuditEvent is not backwards compatible when using MongoDB and upgrading to 6.7.0

[ArnauAregall]

Overview of the issue

The v6.7.0 upgrade removes the following annotation of PersistentAuditEvent:

@Field("event_id"),

I understand the goal is just to use standard @Id and _id as ID's of the jhi_persistent_audit_event collection documents, but this is not compatible with previous records, so when finding by ID field the query won't look anymore for the event_id field, thus documents stored before migrating won't be found.

Motivation for or Use Case

I think the generator should be smart enough to know if is a fresh generation or an upgrade, and conditionally either remove the @Field annotation or replace it with @Field(value = "event_id", targetType = FieldType.OBJECT_ID) which is compatible.

Reproduce the error

• Generate a monolith with MongoDB using JHipster 6.5.3 (my case, don't know if 6.6.x is affected).
• Run the application, and login with admin to generate an audit event.
• HTTP GET /management/audits/{id} to see it returns 200 with the audit event.
• Upgrade to 6.7.0.
• Run the application, and replay the request: will return 404.

Related issues

Suggest a Fix

I think the generator should be smart enough to know if is a fresh generation or an upgrade, and conditionally either remove the @Field annotation or replace it with @Field(value = "event_id", targetType = FieldType.OBJECT_ID) which is compatible.

JHipster Version(s)

Upgraded to 6.7.0 from 6.5.3.

JHipster configuration

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

Browsers and Operating System

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

[murdos]

I removed this annotation during Spring Boot 2.2 upgrade because there was a conflict error between both annotations (@Id and @Field("event_id")).
While doing this, I thought that it could indeed be a breaking change for existing application, and thus I did a test, by generating an application with previous JHipster release, to verify how Spring was handling the ambiguous declaration using the 2 annotations.
I came to the conclusion that Spring was prioritizing @Id and thus using _id and that there was no breaking change, but it seems that I was wrong...

I don't really know what we should do, since re-adding @Field(value = "event_id", targetType = FieldType.OBJECT_ID) would again be a breaking change for users that have generated applications with version 6.7.0 or that have already handled manually the issue.

[patrickjp93]

Honestly as a Joe Average community member I think the best way forward is document it as a mistake that was made and amend the upgrade notes section of the site to handle this, which may very well including renaming the field in old records manually OR using this @Field annotation fix manually before running the upgraded application. Maybe even a dedicated "upgrade quirks" page. You can't smooth this over with a default hotfix to the main generator, so making the quirk very visible in the documents and offering the options for compatibility gives the community both transparency and options/control. Maybe we can make a "Mongo-Pre-6.7.0 compatibility" sub-generator or place an optional flag in the main generator if a programmatic fix is demanded? It's fugly and requires maintenance going forward though.

Covering up/bandaiding a breaking change with another breaking change has never worked out well for communities, using Golang as an example. Put the word out about the flaw in the 6.7.0 and 6.7.1 release notes at the very least.

[ArnauAregall]

I agree that a good approach could be just an awareness message on the release notes, or upgrade guide.

As an extensive JHipster user I would appreciate a clear and concise message of all breaking changes like this one, with an explanation of why is breaking, why is not covered by the automatic upgrade process, and the possible side effects I may expect if I don't deal with it.

I personally don't expect JHipster generator to automate every single upgrade process, but for sure I expect the automatic upgrade will not break any working feature without being aware of it upfront.

[pascalgrimaud]

I'd like to know if you used the jhipster upgrade or a manual upgrade process ?

Then, can you contribute and improve the release note at https://github.com/jhipster/jhipster.github.io plz ?

[ArnauAregall]

My upgrade was manual in this case. I will try to open a PR this weekend then.

[pascalgrimaud]

Thanks a lot @ArnauAregall :)

[pascalgrimaud]

any news @ArnauAregall ?

[ArnauAregall]

any news @ArnauAregall ?

Sorry, I will try to do it soon, please count that I'll do it 😄

[ArnauAregall]

@pascalgrimaud just opened https://github.com/jhipster/jhipster.github.io/pull/917

[pascalgrimaud]

fixed by https://github.com/jhipster/jhipster.github.io/pull/917