Auditing broken for entities using optimistic locking via version properties [DATAMONGO-2139]

[spring-projects-issues]

iqjumps opened DATAMONGO-2139 and commented

Entity class A has Id, version and auditing fields:

 

@Data
@Document
public class A {
  @Id String id;
  @Version Long version;
  @CreatedDate Date createdAt;
  @LastModifiedDate Date lastModifiedAt;
}

 

and I tried to save new A,

ARepository.save(new A());

but result document stored in mongodb doesn't have createdAt field. (only lastModifiedAt field exists)

 

In doInsert() in MongoTemplate, it set 0 to version field

T toSave = entity.initializeVersionProperty();

and then IsNewAwareAuditingHandler checks whether entity is new using IsNewStrategy,

but version field is already set to 0, so it's not new object.

So CreatedXX fields are not touched.

 

I don't know it's intended

---

Affects: 2.1.2 (Lovelace SR2)

Issue Links:

• DATAMONGO-2128 DuplicateKeyException since upgraded to SpringBoot 2.1 when using Optimistic Locking
  ("is duplicated by")
• DATAMONGO-2127 @CreatedDate and @CreatedBy are not set anymore after upgrading Spring Boot to 2.1.0
  ("is duplicated by")
• DATAMONGO-2179 CreatedDate is null for entities using optimistic locking via version property when saving/inserting in batch
  ("is duplicated by")
• DATAMONGO-2150 Auditing broken for entities using optimistic locking via version properties in reactive mongo

Backported to: 2.1.3 (Lovelace SR3)

0 votes, 7 watchers

[spring-projects-issues]

Oliver Drotbohm commented

MappingContextIsNewStrategyFactory.doGetIsNewStrategy(…) uses ….propertyIsNullOrZeroNumber(…), i.e. entities with either null or 0 as version property should be considered new. Can you provide an example showing that this is not working?

[spring-projects-issues]

iqjumps commented

I forked and added a test for this issue:

• https://github.com/iqjumps/spring-data-mongodb.git

• iqjumps@0663e2b

 

This test fails in case of "@Version Long version" and not fail in case of "Long version"

Please check it

 

Thanks

[spring-projects-issues]

iqjumps commented

I found simple workaround.
If I change version field to primitive type("@Version Long version" to "@Version long version"), it works well.
If you don't have plan to fix it, please modify your document.

Thanks

[spring-projects-issues]

iqjumps commented

Above workaround has problem in update case.
After success to insert, updating same entity using Repository:save() method performs as insert operation because SimpleMongoRepository uses same isNewStrategy.

public <S extends T> S save(S entity) {

	Assert.notNull(entity, "Entity must not be null!");

	if (entityInformation.isNew(entity)) {
		return mongoOperations.insert(entity, entityInformation.getCollectionName());
	}

	return mongoOperations.save(entity, entityInformation.getCollectionName());
}

So it throws duplicate key error.
To avoid this error, I have to use MongoTemplate directly

[spring-projects-issues]

mle-enso commented

I can confirm especially the behavior on Repository#save() when using Spring Boot 2.1.0.

To be more clear: I save an entity with primitive long @Version field and get it back, properly saved, with version 0. Saving it again, now with its assigned id but still version 0, results in a duplicate key exception. Up until Spring Boot 2.0.6 everything worked fine here

[spring-projects-issues]

Oliver Drotbohm commented

Would anyone affected mind to try the latest snapshots (either 2.1.3.BUILD-SNAPSHOT or 2.2.0.BUILD-SNAPSHOT). Those builds contain a patch that should fix this. Feedback welcome

[spring-projects-issues]

Jens Meiss commented

Oliver Drotbohm can't find the version in the repo:

• http://repo.spring.io/snapshot/org/springframework/boot/spring-boot-starter-data-mongodb/ 

or is it the wrong repository? :)

 

[spring-projects-issues]

Oliver Drotbohm commented

It's the wrong artifact you're looking for. As you seem to be using Boot, please upgrade by setting the spring-data-releasetrain.version property to Lovelace-BUILD-SNAPSHOT or Moore-BUILD-SNAPSHOT in your build

[spring-projects-issues]

Jens Meiss commented

oh, thanks! :)

from my side it lookes like the bug is fixed (y)

i used the Lovelace-BUILD-SNAPSHOT

 

anyone else who want to try this, the documentation on how to use a release train version can be found here: 

• https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-build-systems.html

[spring-projects-issues]

René Reitmann commented

My tests are green as well (https://github.com/dzhw/missing-created-properties) :)

Thanks!

[spring-projects-issues]

Oliver Drotbohm commented

Lovely guys, thanks for the feedback! And sorry for the hassle in the first place

[spring-projects-issues]

Mike Pellegrini commented

I am experiencing the same issue when using reactive flavor of MongoDB starter. Have tried with the following:

<parent>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-parent</artifactId>
   <version>2.1.1.BUILD-SNAPSHOT</version>
   <relativePath/> <!-- lookup parent from repository -->
</parent>

also tried with 

<properties>
       <spring-data-releasetrain.version>Moore-BUILD-SNAPSHOT</spring-data-releasetrain.version>
</properties>

and 

<properties> <spring-data-releasetrain.version>Lovelace-BUILD-SNAPSHOT</spring-data-releasetrain.version> </properties>

This works as expected when using Spring Boot 2.0.6.

If I create an a spring boot app with non-reactive MongoDB and use either release train as mentioned above.  Then like others the @CreatedDate field is set.

Any ideas? It is as basic of a an example as you could possibly get, so should be easy to recreate.

 

 

[spring-projects-issues]

Oliver Drotbohm commented

It looks like we missed to also fix the reactive implementations. Would you mind creating a new ticket for this?

[spring-projects-issues]

Mike Pellegrini commented

Thanks.  I new ticket was created for this here https://jira.spring.io/browse/DATAMONGO-2150