generator-jhipster: constraint [pk_jhi_persistent_audit_event] violation;
Overview of the issue
Motivation for or Use Case
This issue persist on very basic operations like login without any for me observable/explainable behaviour so only option I have after getting this is to truncate audit tables. I don’t like to do that on the production.
Reproduce the error
PersistentAuditEvent was not tampered with, issue just have appeared with JHipster 4.14.1 and PostgreSQL 10.4
Related issues
Suggest a Fix
JHipster Version(s)
I’m using JHipster 4.14.1 and have not used any other version below so can’t tell wether this is the regression. I just have found similar unresolved issue on SO.
JHipster configuration
##### **JHipster configuration, a .yo-rc.json` file generated in the root folder**
.yo-rc.json file
{
"generator-jhipster": {
"promptValues": {
"packageName": "com.driveme",
"nativeLanguage": "en"
},
"jhipsterVersion": "4.14.1",
"baseName": "backend",
"packageName": "com.driveme",
"packageFolder": "com/driveme",
"serverPort": "8080",
"authenticationType": "jwt",
"cacheProvider": "ehcache",
"enableHibernateCache": true,
"websocket": "spring-websocket",
"databaseType": "sql",
"devDatabaseType": "h2Disk",
"prodDatabaseType": "postgresql",
"searchEngine": false,
"messageBroker": false,
"serviceDiscoveryType": false,
"buildTool": "maven",
"enableSocialSignIn": true,
"enableSwaggerCodegen": false,
"jwtSecretKey": "replaced-by-jhipster-info",
"clientFramework": "angularX",
"useSass": true,
"clientPackageManager": "npm",
"applicationType": "monolith",
"testFrameworks": [],
"jhiPrefix": "jhi",
"enableTranslation": true,
"nativeLanguage": "en",
"languages": [
"en",
"cs",
"hu",
"sk"
]
}
}
JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory
JDL entity definitions
entity LatLng (lat_lng) {
lat Float,
lng Float
}
entity Address (address) {
city String,
street String,
number String
}
entity DriveOrder (drive_order) {
state EOrderState
}
entity AppUser (app_user)
entity DriveMeUser (drive_me_user) {
driverRole EDriverRole,
isRegComplete Boolean
}
entity Car (car) {
color String,
type String,
model String,
yearMade LocalDate,
regNumPlate String
}
entity Offer (offer) {
priceKm Float,
cost Float,
durationSec Integer,
distanceKm Float,
created ZonedDateTime,
path String,
lastStateChange ZonedDateTime,
offerState EOfferState
}
enum EOrderState {
SAVED,
PENDING,
COMPLETE,
CANCELLED,
IN_PROGRESS,
DRIVER_ARRIVED
}
enum EDriverRole {
DRIVER_CLIENT,
DRIVER_PROVIDER
}
enum EOfferState {
PLACED,
TAKEN,
COMPLETE,
EXPIRED
}
relationship OneToOne {
Address{latLng} to LatLng,
DriveOrder{from} to Address,
DriveOrder{to} to Address,
DriveOrder{user} to DriveMeUser,
DriveMeUser{car} to Car,
DriveMeUser{user} to User,
Offer{provider} to DriveMeUser
}
relationship OneToMany {
DriveOrder{offers} to Offer{driveOrder}
}
Environment and Tools
openjdk version “1.8.0_172” OpenJDK Runtime Environment (build 1.8.0_172-b11) OpenJDK 64-Bit Server VM (build 25.172-b11, mixed mode)
git version 2.18.0
node: v8.9.1
npm: 6.1.0
bower: 1.7.9
gulp: [20:23:31] CLI version 3.9.1
yeoman: 1.8.5
Congratulations, JHipster execution is complete!`
Entity configuration(s) entityName.json files generated in the .jhipster directory
Browsers and Operating System
Arch Linux
- [x ] Checking this box is mandatory (this is just to show you read everything)
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 17 (10 by maintainers)
I received an answer on my Stack Overflow question that seems reasonable.
Add
rollbackFor=Exception.classon theadd()method inCustomAuditEventRepository.If the auditing fails, it’s not a big deal. At least the app still works!
Thanks @erikyuzwa - I’ll need to check our database on https://start.jhipster.tech but indeed those tables take a lot of spaces, and are redundant with the logs. I’ll need to do a poll and ask people before doing this, but I’d like to remove those tables.
I’d love to have an option to disable auditing since I don’t really need it and it causes problems.
Using UUID is something that comes back quite often - I’ve always been opposed to it from a technical perspective, but the more times passes, the more I like the idea. That’s definitely something worth considering, but of course that would be for a major release (JHipster 6).
Anyway, back to the current issue: this is something I’ve never experienced, and I don’t know how to reproduce. I’m pretty sure having a sequence of 1 doesn’t help, and at least that must cause a huge performance impact, so I would advise to go back to 50.
Oh, and speaking of JHipster 6: I’m not totally happy with all the audit stuff. There is a performance penalty, and I’m not sure that many people need it or even use it. So maybe we should altogether remove it, and we’ll need to make some user surveys in the next months to learn more about usage patterns.
The project was generated with an earlier version of jhipster (3.0.2 as indicated by jhipster-core/package.json), upgraded a few weeks ago (yo-rc.json is now showing “jhipsterVersion”: “4.13.3”).
It is not a PostgreSQL problem, nor MS SQL Server (tried with both Linux and Windows versions), it is rather related to the management of numeric sequences (the value obtained from hibernate_sequence seems to be behind with several units after application restart). I am using an increment of 1 for the hibernate_sequence (initially it was 50). After a new deployment, the login works only after several retries. Afterwards, it is all OK until a new deployment happens. Using UUIDs will resolve this problem in a future project.