Problems getting JPA webapi branch to work

Chris_Knoll · February 24, 2015, 10:39pm

I read on some of the discussion on this: doing things through git means that the file has to pass through git to be processed. If you are developing migrations on your local workstations and you migrate them before committing them, you’re already screwed (because your native CRLF has now polluted the checksum).

They say they were working on something to address this for the 4.0 release, sometime in the spring.

-Chris

alfranke · March 3, 2015, 6:49pm

See following pull request comment for details on what to do after pulling down .gitattributes file. This should fix the checksum problem, ensuring that *.sql files have LF line endings in both repository and working directory:

github.com/OHDSI/WebAPI

Initial .gitattributes file. Normalize eol. Fix Flyway checksum validation error

OHDSI:master ← OHDSI:eol-gitattributes-flyway-checksum

opened 06:34PM - 03 Mar 15 UTC

alexfranken

+15 -0

.gitattributes should help ensure that eol characters are normalized when writin…g to the repository. This should prevent messy diffs (e.g. where it looks like the whole file changed) & Flyway checksum validation errors, regardless of the value of 'git config --global core.autocrlf'. For Flyway, the .gitattributes basically says always convert *.sql to 'lf' when writing to the object database as well as the working directory. Below are steps to take to “refresh” existing cloned repo, after modifying .gitattributes 1.) mvn clean (remove target dir) 2.) git rm –cached –r * 3.) git reset --hard To confirm a file had LF, I used *nix `file src/main/resources/db/migration/oracle/V1.0.0.1__schema_create_spring_batch.sql` The output should mention 'ascii text' (not 'ascii text with CRLF'). For our environment, where the schema was created via Flyway on a Windows machine (with core.autocrlf=true), I then dropped all Flyway managed objects and re-ran migrations. More on the Flyway issue: https://github.com/flyway/flyway/issues/253