midas-framework / midas

A framework for Gleam, Midas makes shiny things.
https://hex.pm/packages/midas
190 stars 5 forks source link

DB access #12

Open CrowdHailer opened 4 years ago

CrowdHailer commented 4 years ago

PG Client

https://github.com/erleans/pgo is a library with a very simple interface. Pretty easy to wrap up in Gleam, at least at a low level.

Migrations

Using a separate tool for migrations seems a very sensible approach to reduce the amount of things needed to build today.

diesel_cli has a binary that is easy to use :+1: diesel docs are mostly explained in the context of rust projects and diesel :-1:

DataMapping

Left as an unsolved problem at this stage

Questions.

  1. How to instal diesel without Cargo
  2. Can pgo, be configured with a DATABASE_URL, everything else is and it would make config simpler
CrowdHailer commented 4 years ago

Turns out diesel is not easy to instal without cargo. But there is nothing in principle preventing using precompiled binaries https://github.com/diesel-rs/diesel/issues/2379

A fallback could be a multistage build where the first step only installs diesel and copies accross to a working image based on the offical gleam image

lpil commented 4 years ago

I would be happy to contribute both a migrations guide to MIdas and a DATABASE_URL support to pgo (or the Gleam wrapper).

CrowdHailer commented 4 years ago

@lpil Both would be great, if you find the time.

CrowdHailer commented 4 years ago

Opened up an issue on pgo for the suggestion of adding configuration by database_url https://github.com/erleans/pgo/issues/34

CrowdHailer commented 4 years ago

This is the last issue for 0.2, I think I will probably do something ugly in the config file of this project until DATABASE_URL is usable everywhere

CrowdHailer commented 4 years ago

This commit adds handling DB url in the template project. https://github.com/midas-framework/template/commit/e4f227daa60774329c95c5d9b6faac97df550fbc#diff-db12b97059813e401c06928c7234d2c0R22-R30

It should be moved to midas lib before 0.2

CrowdHailer commented 4 years ago

There are several levels to this.

  1. Nice wrapper around pgo. Safe if you write parameterised queries. Requires inline SQL. Probably ok to work with if willing to take care on defining you queries and making reusable transformation functions from a dynamic response. No need for DB access at development time. https://devblogs.microsoft.com/dotnet/build-a-web-service-with-f-and-net-core-2-0/

  2. yesql level, e.g. https://github.com/tdammers/yeshql Requires more non SQL syntax. Also doesn't require contact to a DB. Possible to get your types wrong. But I consider this a perimeter issue, the same as when using usafe_cast to implement gen call/reply. If defined correctly then the type system ensures consistency through the rest of the project. In case of bugs perimeter assumptions (foundation axioms) are the first thing to check.

  3. Type providers. ecamples sqlx(rust) rezoom.sql (fsharp) These are impressive, have a lot of safety. They make some use of the database to find out schemas, though rezoom uses the migration. Comes with quite a lot of complexity as they have to parse SQL queries. Also rezoom has it's own SQL dialect, and I don't think a general purpose migration tool would work with it.

Questions