Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Error saving new field "COMMIT_DATE_INSTANT" and creating tables on version 5.1.0 #765
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:
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.
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)))
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.
added a commit
Jan 4, 2019
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:
`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