inconsistent datetime results in repository methods

[bilak]

Hello,
I'm using spring data jpa with postgresql. I'm storing times using javas OffsetDateTime. I know that underlying type in postgresql truncates date to microseconds and I'm ok with that. However there is difference between results of save vs get.

So for example when I do following:

final SampleObject sample = new SampleObject();
sample.setBusinessDate(OffsetDateTime.now());
sample.setId(UUID.randomUUID());

final SampleObject savedSample = sampleObjectRepository.save(sample);

final SampleObject loadedSample = sampleObjectRepository.findById(savedSample.getId()).orElseThrow();

assertThat(savedSample, is(loadedSample));

the test fails because savedSample.businessDate contains nanoseconds while loadedSample.businessDate doesn't contain nanos. Is there any way how we can get the dates from save also truncated to micros?

sample project

[schauder]

Is there any way how we can get the dates from save also truncated to micros?
No.
Save returns either the the instance passed into save, potentially with an updated, id, version, and auditing data or an instance with the same information that was already in present in the persistence context.

The truncation happens in the database.
In order to obtain an instance that represents these changes Spring Data JPA would have to evict the just saved entity and reload it from the database.
This would cause a sever performance penalty, with no positive effect for 99% of the users and it would break many existing applications, because now the original entity is no longer a managed JPA entity.
This could cause various exceptions and even loss of data without any exception.

Of course, in your special case you can always evict the entity and reload it in order to get the behaviour you want.

[bilak]

but then could we have some mechanism that will truncate all dates on entity to requested format?
Something similar to DateTimeProvider used in auditing?

@Bean(DATETIME_PROVIDER)
public DateTimeProvider auditingDateTimeProvider(Clock clock) {
  return () -> Optional.of(DateTimeUtil.nowWithMicrosPrecision(clock));
}

[schauder]

No, that's complete out of scope for a library trying to make persistence easy and consistent to use.