Use base database

[alovak]

As part of #120 with this PR we are replacing internal/database with base/database package. Major change is that now we have /migations where all migrations are stored.

Some issues/concerns:

• base/config can't be used out of the box right now as a replacement for Customers' configuration as it does not support environment variables. It reads config from the file. After we update base/config to work with env variables then we can replace Config in customers. Temporary Config is created.
• we should backup production DB as I have no idea how this new migrations may affect production DB (as all migrations will be run on deploy) 🤷‍♂️ -> to avoid this we can manually create (schema_migrations table and insert value of last migration (15))...
• I don't know how OSS users will be affected by this migration (they may be on different versions, etc.). I don't see the easy way to migrate. (here is an raw idea) -> One way would be to ask them to upgrade to 0.4 version if they still are not, in 0.5 we can create schema_migrations table and insert number so next time migrations from /migrations will be skipped, in 0.6 we can migrate, ...

Tasks:

• [x] replace internal/database with base/database

• [x] create separate migration files in /migrations

• [x] update makefile to generate file with embedded migrations (they are embedded into go file using pkger)

• [x] fix all loggers to follow new base/log interface

• [x] squash migrations

• [x] create instructions on how to update to v0.5 (dump; drop; create;load)

• [x] update docs with instructions on how to embed migrations (install pkger; make embed-migrations)

[adamdecaf]

re: deployment in prod - I'm going to take a backup and move the tables to backfill with the new schemas. Will take a few minutes to do, so I'm not worried.

For OSS folks we will announce that v0.5 is a breaking change with this and they'll need to follow steps similar to what I end up doing.

[alovak]

@adamdecaf

re: deployment in prod - I'm going to take a backup and move the tables to backfill with the new schemas. Will take a few minutes to do, so I'm not worried.

then we have to manually create migration table (schema_migrations) and insert number of the latest migration there... or our application during the next run will run all migrations again.

is it ok?

[adamdecaf]

We don't need to manually create any tables. The migrator library creates them for us.

[alovak]

Oh. Rigth. So I'll add it to /migrations

[codecov-io]

Codecov Report

Merging #253 into master will increase coverage by 0.12%. The diff coverage is 51.20%.

@@            Coverage Diff             @@
##           master     #253      +/-   ##
==========================================
+ Coverage   61.43%   61.56%   +0.12%     
==========================================
  Files          52       50       -2     
  Lines        3021     2901     -120     
==========================================
- Hits         1856     1786      -70     
+ Misses        832      803      -29     
+ Partials      333      312      -21     

[adamdecaf]

I see CI failing and I think we should run the same steps CI is doing locally to figure out what's going wrong.

[adamdecaf]

Great work Pavel!