Add migration scripts for some tables

[bickelj]

These are the minimal tables in the draft entity relationship diagram
required to start working with opportunities and applications.

Issue #8 Set up schema

Co-authored by: Daniel Schultz slifty@gmail.com

[bickelj]

I will come back to the GitHub migrate action in the morning, but I encourage you to see if this works locally.

[slifty]

I would love to see these added in the context of their use -- that way we avoid situations where we realize the table definition doesn't work for our API use case.

Now that we have all of the layers set up, what do you think about focusing on implementing a specific endpoint top-to-bottom (migration + route + buisness logic)?

[bickelj]

I would love to see these added in the context of their use -- that way we avoid situations where we realize the table definition doesn't work for our API use case.

Now that we have all of the layers set up, what do you think about focusing on implementing a specific endpoint top-to-bottom (migration + route + buisness logic)?

That is also fine. I don't think it would change the order of development, meaning I would still need a database to write to in order to develop routes, handlers, etc. Also in the spirit of Continuous Integration we don't want long-lived branches. But yes, I agree that it will affect the design by making sure it can be used in the context it's supposed to be used, etc. Makes sense.

These tables are the minimal ones needed for opportunities and applications, i.e. the two endpoints described in the present draft OpenAPI document.

[codecov-commenter]

Codecov Report

Merging #29 (f5c08ac) into main (62920b0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #29   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            4         4           
  Lines           20        20           
=========================================
  Hits            20        20           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62920b0...f5c08ac. Read the comment docs.

[bickelj]

I forgot to mention why I did bigint: I guess I prefer the ids to be bigint so we have the least chance of ever rolling over. I know 2 billion is a "lot" but there are dbs out there where even bigint rolls over. The other thing I did was try to align the columns largest to smallest, so it goes 8 bytes (id), 8 bytes (timestamp), smaller than 8 bytes, smaller still, etc. That's just for space efficiency and probably premature optimization. Then again you cannot really go back and re-align them, I don't think, so may as well do it now.

[bickelj]

I think I already mentioned a "why" on the varchar: it's the same type as text when the character limit is not specified, while also making it more portable/iso/ansi. Again not a big deal either way, because it looks like we're firmly postgres and that's good, but just explaining why.

[bickelj]

I also realize on delete cascade is controversial. I am OK with leaving it out, but I would rather have my delete work when I call it instead of having to go through each and every table. Using delete should raise alarm bells and be very rare anyway.

[bickelj]

One more thing to consider is whether to make them more idempotent, e.g. create table if not exists ... rather than create table .... The docs recommended idempotence. Liquibase has a concept of preconditions built-in, I didn't check to see if this tool has the same, but it's along the same lines conceptually.

[slifty]

I pulled the canonical_fields migration over to #55!

[slifty]

I think we can close this as well; we have a good migrations pattern (and can always reference this PR even after it's closed)