DB access

[CrowdHailer]

No description provided.

[CrowdHailer]

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 http://diesel.rs/guides/getting-started/
• flyway https://flywaydb.org/getstarted/java

diesel_cli has a binary that is easy to use 👍 diesel docs are mostly explained in the context of rust projects and diesel 👎

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]

Turns out diesel is not easy to instal without cargo. But there is nothing in principle preventing using precompiled binaries diesel-rs/diesel#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]

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

[CrowdHailer]

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

[CrowdHailer]

Opened up an issue on pgo for the suggestion of adding configuration by database_url erleans/pgo#34

[CrowdHailer]

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]

This commit adds handling DB url in the template project. midas-framework/template@e4f227d#diff-db12b97059813e401c06928c7234d2c0R22-R30

It should be moved to midas lib before 0.2

[CrowdHailer]

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.

• https://github.com/launchbadge/sqlx
• https://news.ycombinator.com/item?id=14893563
• https://www.reddit.com/r/programming/comments/6qizpb/statically_typed_sql_for_f/

Questions

• Do useful production systems exist at this level 1? if no then it's a waste of time putting much effort into promoting Midas before higher levels are achieved.