Generator-jhipster: With auditing creation date should be constand, modification date updates
Overview of the issue
By extending AbstractAuditingEntity it is possible to keep track of created date and modified date.
But the created date and modified date are both changed with every update of the entity.
Reproduce the error
Create a project add a user, change it and check the created and last modified date in the database (or on screen) both created date and last modified date will be equall but should be different (created should stay equal to first version)
Related issues
First mentioned here https://github.com/jhipster/jhipster-core/issues/24
Suggest a Fix
change: AbstractAuditingEntity.java
private Instant createdDate = Instant.now();
to:
private Instant createdDate;
as described here:
https://programmingmitra.blogspot.com/2017/02/automatic-spring-data-jpa-auditing-saving-CreatedBy-createddate-lastmodifiedby-lastmodifieddate-automatically.html
JHipster Version(s)
any version
JHipster configuration
- [X] Checking this box is mandatory (this is just to show you read everything)
tibistibi
All 14 comments
@tibistibi I don't see many people using the auditing part, and I was thinking we could remove it - as you are a frequent contributor and as you are using it, do you think its worth keeping it in the generator?
Also, this ticket makes me think not a lot of people use it for real.
jdubois
on 28 Nov 2018
in practice it really nice to have creation/modification data. for debugging and things like who did this and when was this changed, you want this feature.
so i think its a good idea of jhipster to add this out of the box as an example.
the problem with the date is only small and my change will fix it. although (indeed) it shows not many use it because this bug has been here long (or people just fix it locally and to not add it here).
tibistibi
on 28 Nov 2018
and if i knew how this works earlier i would have added this to all my important entities.
tibistibi
on 28 Nov 2018
If we keep auditing, I think we should change it to use UUIDs to fix the duplicate key issues I've seen in 21-Points Health.
https://github.com/mraible/21-points/issues/50
On Nov 28, 2018, at 07:08, Tibor Strausz notifications@github.com wrote:
and if i know how this works earlier i would have added this to all my important entities.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
mraible
on 28 Nov 2018
Also if we keep it, we should add a cron job which removes entries older
than a month to avoid flooding the Db. If someone needs older entries they
can decide to remove/modify the job
On Wed, 28 Nov 2018, 4:14 pm Matt Raible <[email protected] wrote:
If we keep auditing, I think we should change it to use UUIDs to fix the
duplicate key issues I've seen in 21-Points Health.https://github.com/mraible/21-points/issues/50
On Nov 28, 2018, at 07:08, Tibor Strausz notifications@github.com
wrote:and if i know how this works earlier i would have added this to all my
important entities.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8895#issuecomment-442481980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF7bPOmrI5BdBZ-8Bpmy1lX76vKpIks5uzqg9gaJpZM4Y3gpI
.
deepu105
on 28 Nov 2018
in my understanding these fields are columns added to the jhi_user tables so it does not grow.
here is my table:
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| login | varchar(100) | NO | UNI | NULL | |
| password_hash | varchar(60) | YES | | NULL | |
| first_name | varchar(50) | YES | | NULL | |
| last_name | varchar(50) | YES | | NULL | |
| email | varchar(100) | YES | UNI | NULL | |
| image_url | varchar(256) | YES | | NULL | |
| activated | bit(1) | NO | | NULL | |
| lang_key | varchar(6) | YES | | NULL | |
| activation_key | varchar(20) | YES | | NULL | |
| reset_key | varchar(20) | YES | | NULL | |
| created_by | varchar(50) | NO | | NULL | |
| created_date | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| reset_date | timestamp | YES | | NULL | |
| last_modified_by | varchar(50) | YES | | NULL | |
| last_modified_date | timestamp | YES | | NULL | |
| status | varchar(20) | NO | | NULL | |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
@mraible and @deepu105 are we talking about the same thing?
tibistibi
on 28 Nov 2018
when updaing according to my suggestion above the test case in UserResourceIntTest.java should be changed to this:
@Test
public void testUserDTOtoUser() {
UserDTO userDTO = new UserDTO();
userDTO.setId(DEFAULT_ID);
userDTO.setLogin(DEFAULT_LOGIN);
userDTO.setFirstName(DEFAULT_FIRSTNAME);
userDTO.setLastName(DEFAULT_LASTNAME);
userDTO.setEmail(DEFAULT_EMAIL);
userDTO.setActivated(true);
userDTO.setImageUrl(DEFAULT_IMAGEURL);
userDTO.setLangKey(DEFAULT_LANGKEY);
userDTO.setCreatedBy(DEFAULT_LOGIN);
userDTO.setLastModifiedBy(DEFAULT_LOGIN);
userDTO.setAuthorities(Collections.singleton(AuthoritiesConstants.USER));
User user = userMapper.userDTOToUser(userDTO);
assertThat(user.getId()).isEqualTo(DEFAULT_ID);
assertThat(user.getLogin()).isEqualTo(DEFAULT_LOGIN);
assertThat(user.getFirstName()).isEqualTo(DEFAULT_FIRSTNAME);
assertThat(user.getLastName()).isEqualTo(DEFAULT_LASTNAME);
assertThat(user.getEmail()).isEqualTo(DEFAULT_EMAIL);
assertThat(user.getActivated()).isEqualTo(true);
assertThat(user.getImageUrl()).isEqualTo(DEFAULT_IMAGEURL);
assertThat(user.getLangKey()).isEqualTo(DEFAULT_LANGKEY);
assertThat(user.getCreatedBy()).isNull();
assertThat(user.getCreatedDate()).isNull();
assertThat(user.getLastModifiedBy()).isNull();
assertThat(user.getLastModifiedDate()).isNull();
assertThat(user.getAuthorities()).extracting("name").containsExactly(AuthoritiesConstants.USER);
}
these linese are the point:
assertThat(user.getCreatedDate()).isNull();
assertThat(user.getLastModifiedDate()).isNull();
hi @tibistibi
are you sure about this ?
Create a project add a user, change it and check the created and last modified date in the database (or on screen) both created date and last modified date will be equall but should be different (created should stay equal to first version)
I test it by adding a new user and update him later and the created date was not modified.
The column is defined as not updatable with this :
@Column(name = "created_date", updatable = false)
With this config hibernate should not adding this column on the update request and so the created_date should never be changed.
avdev4j
on 29 Nov 2018
what db do you use?
and yes i expected to work like that but it did not. i have the same line but still it is updated, 100% sure.
MariaDB []> select id, created_date, last_modified_date from jhi_user;
+-----+---------------------+---------------------+
| id | created_date | last_modified_date |
+-----+---------------------+---------------------+
| 1 | 2018-02-02 09:48:55 | NULL |
| 2 | 2018-02-02 09:48:55 | NULL |
| 3 | 2018-02-02 09:48:55 | 2018-02-10 23:05:21 |
| 4 | 2018-08-28 09:47:15 | 2018-08-28 09:47:15 |
| 5 | 2018-02-02 10:40:30 | 2018-03-14 14:41:46 |
| 6 | 2018-08-28 09:47:15 | 2018-08-28 09:47:15 |
| 7 | 2018-02-05 11:22:25 | 2018-03-14 15:34:43 |
| 8 | 2018-02-07 15:08:53 | 2018-03-14 15:34:34 |
| 9 | 2018-10-31 12:23:25 | 2018-10-31 12:23:25 |
| 10 | 2018-02-10 23:05:59 | 2018-02-10 23:06:21 |
| 11 | 2018-10-30 12:35:26 | 2018-10-30 12:35:26 |
| 12 | 2018-02-23 17:20:38 | 2018-02-23 17:23:31 |
| 13 | 2018-10-17 14:57:47 | 2018-10-17 14:57:47 |
...
diff's between the dates stop in august maybe an update changed this behaviour?
in any case it is trange to let spring fill in the modifiedby and createdby but add createdDate and modifiedDate our selves. they can all be left empty and spring will do her work.
tibistibi
on 29 Nov 2018
ok seems to have a wrong table definition looking into it why it happened but this will be the real problem:
| created_date | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
so my bad!
i will close this issue
tibistibi
on 29 Nov 2018
tested it and it seems that MariaDb will automatically add these default and extra value if you have a timestamp field which is not null
tibistibi
on 29 Nov 2018
Happy to see it's now resolved but what a strange behaviour from maria....
avdev4j
on 29 Nov 2018
yes and good to know just for information completeness here what happens
MariaDB [sbysStaging]> desc jhi_user;
+--------------------+--------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| login | varchar(100) | NO | UNI | NULL | |
| password_hash | varchar(60) | YES | | NULL | |
| first_name | varchar(50) | YES | | NULL | |
| last_name | varchar(50) | YES | | NULL | |
| email | varchar(100) | YES | UNI | NULL | |
| image_url | varchar(256) | YES | | NULL | |
| activated | bit(1) | NO | | NULL | |
| lang_key | varchar(6) | YES | | NULL | |
| activation_key | varchar(20) | YES | | NULL | |
| reset_key | varchar(20) | YES | | NULL | |
| created_by | varchar(50) | NO | | NULL | |
| created_date | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| reset_date | timestamp | YES | | NULL | |
| last_modified_by | varchar(50) | YES | | NULL | |
| last_modified_date | timestamp | YES | | NULL | |
| status | varchar(20) | NO | | NULL | |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
17 rows in set (0.00 sec)
MariaDB [sbysStaging]> alter table jhi_user change created_date created_date timestamp null default null;
Query OK, 0 rows affected (0.08 sec)
Records: 0 Duplicates: 0 Warnings: 0
MariaDB [sbysStaging]> desc jhi_user;
+--------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+---------+----------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| login | varchar(100) | NO | UNI | NULL | |
| password_hash | varchar(60) | YES | | NULL | |
| first_name | varchar(50) | YES | | NULL | |
| last_name | varchar(50) | YES | | NULL | |
| email | varchar(100) | YES | UNI | NULL | |
| image_url | varchar(256) | YES | | NULL | |
| activated | bit(1) | NO | | NULL | |
| lang_key | varchar(6) | YES | | NULL | |
| activation_key | varchar(20) | YES | | NULL | |
| reset_key | varchar(20) | YES | | NULL | |
| created_by | varchar(50) | NO | | NULL | |
| created_date | timestamp | YES | | NULL | |
| reset_date | timestamp | YES | | NULL | |
| last_modified_by | varchar(50) | YES | | NULL | |
| last_modified_date | timestamp | YES | | NULL | |
| status | varchar(20) | NO | | NULL | |
+--------------------+--------------+------+-----+---------+----------------+
17 rows in set (0.00 sec)
MariaDB [sbysStaging]> alter table jhi_user change created_date created_date timestamp not null;
Query OK, 41 rows affected (0.11 sec)
Records: 41 Duplicates: 0 Warnings: 0
MariaDB [sbysStaging]> desc jhi_user;
+--------------------+--------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| login | varchar(100) | NO | UNI | NULL | |
| password_hash | varchar(60) | YES | | NULL | |
| first_name | varchar(50) | YES | | NULL | |
| last_name | varchar(50) | YES | | NULL | |
| email | varchar(100) | YES | UNI | NULL | |
| image_url | varchar(256) | YES | | NULL | |
| activated | bit(1) | NO | | NULL | |
| lang_key | varchar(6) | YES | | NULL | |
| activation_key | varchar(20) | YES | | NULL | |
| reset_key | varchar(20) | YES | | NULL | |
| created_by | varchar(50) | NO | | NULL | |
| created_date | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| reset_date | timestamp | YES | | NULL | |
| last_modified_by | varchar(50) | YES | | NULL | |
| last_modified_date | timestamp | YES | | NULL | |
| status | varchar(20) | NO | | NULL | |
+--------------------+--------------+------+-----+-------------------+-----------------------------+
17 rows in set (0.00 sec)
Related issues
tomj0101
·
3Comments
trajakovic
·
4Comments
DanielFran
·
3Comments
SudharakaP
·
3Comments
Steven-Garcia
·
3Comments
Most helpful comment
in practice it really nice to have creation/modification data. for debugging and things like who did this and when was this changed, you want this feature.
so i think its a good idea of jhipster to add this out of the box as an example.
the problem with the date is only small and my change will fix it. although (indeed) it shows not many use it because this bug has been here long (or people just fix it locally and to not add it here).