Error saving new field "COMMIT_DATE_INSTANT" and creating tables on version 5.1.0 #765
Comments
NicoBondarenco
changed the title
|
thanks for reporting, we will fix it |
|
did you do something special to build Instant with nano precision? Which java version and vendor do you have? |
|
My Java version is I don't know if could be it, but maybe the region? I'm from Brazil. I tried to use a custom provider too, and got the same problem. (.withDateTimeProvider(() -> ZonedDateTime.now(ZoneOffset.UTC))) jshell> ZonedDateTime.now() jshell> ZonedDateTime.now().toInstant() jshell> Instant.now() If it is a region problem, maybe the value should follow a custom pattern to avoid these kind of problem, so if I save in one region and read in another, I won't have any problems. |
|
looks like java 10 creates Instant.now() with nano precision while java 8 creats with millis precision. I will fix it |
|
fixed in 5.1.1 |
|
Thanks very much |
|
Still getting the same error in version 5.1.1, and I'm getting some other errors too.
`JaversException SQL_EXCEPTION: Value too long for column "COMMIT_DATE_INSTANT VARCHAR(26)": "'2019-01-05T21:31:38.881609100Z' (30)"; SQL statement: `java.lang.NullPointerException: text ` `org.polyjdbc.core.exception.SchemaManagerException: [DDL_ERROR] Failed to run DDL: Caused by: org.h2.jdbc.JdbcSQLException: Table "JV_COMMIT" already exists; SQL statement: ` |
|
That's really strange. Looks like the root cause on your machine is still Instant serializing. In 5.1.1, I have added the test asserting that Instants are serialized with millis precision, which gives exactly 24 chars at max. it works as expected: Could you set a breakpoint in debugger at |
|
and also you can easily run Javers tests on your machine: |
|
I ran all tests in javers-core with debug and it passes correctly, but when I ran "gradlew javers-core:test" there are some errors. I'm attaching the tests results, and I'll try to do some tests here too. |
|
My problem with the insert of "COMMIT_DATE_INSTANT" seems to be in "org.javers.repository.sql.repositories.CommitMetadataRepository.save()", in this specific serialization: |
|
@NicoBondarenco, nice job, thanks. This is it. Fix is on its way to Central. |
|
fixed in 5.1.2 |
|
second fix for this issue released in 5.1.3 |
|
5.1.2 works correctly, still I noticed exactly the same issue with 5.1.3. |
After the new version (5.1.0), when I use SQLRepository, Javers creates the new field on database like "commit_date_instant varchar(26) DEFAULT NULL" but when I try to call the commit method, I get an error saying:
"JaversException SQL_EXCEPTION: Value too long for column "COMMIT_DATE_INSTANT VARCHAR(26)": "'2019-01-04T11:36:23.572228100Z' (30)"; SQL statement:
INSERT INTO jv_commit ( author, commit_date, commit_date_instant, commit_id, commit_pk ) VALUES ( ?,?,?,?,? ) [22001-197]
while executing sql: INSERT INTO jv_commit ( author, commit_date, commit_date_instant, commit_id, commit_pk ) VALUES ( ?,?,?,?,? )"
Looking in the code, I saw that the "COMMIT_DATE_INSTANT" value is formatted to a String using "DateTimeFormatter.ISO_INSTANT.format(dateInstant)" (org.javers.repository.sql.repositories.CommitMetadataRepository:40). This is generating a String(30).
Is it possible to leave this "DateTimeFormatter.ISO_INSTANT" as a default and create a configuration to format this field? Or alter the column generation to a larger length?
BTW: I'm using Javers with H2 for unit tests. I also tried to use MySQL and got the same problem.
Another thing is, if I'm using Hibernate configuration "hibernate.hbm2ddl.auto" as validate and the tables are already created, Javers is trying to create the tables again on JaversBuilder.build(), then I get an error saying that the tables already exists.
The text was updated successfully, but these errors were encountered: