Npgsql.FSharp.Analyzer
sequelts
Our great sponsors
| Npgsql.FSharp.Analyzer | sequelts | |
|---|---|---|
| 3 | 3 | |
| 137 | 28 | |
| - | - | |
| 0.0 | 0.0 | |
| over 2 years ago | over 1 year ago | |
| C# | TypeScript | |
| MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Npgsql.FSharp.Analyzer
sequelts
-
Kysely: TypeScript SQL Query Builder
You can use these template literal types + infer to build an entire SQL parser. I did a POC that infers SQL query types by parsing the SQL query on a type level:
https://github.com/nikeee/sequelts
However, building this parser is pretty cumbersome and supporting multiple SQL dialects would be lots of pain. While I'm not a fan of query builders per se, Kysely pretty much covers everything that my POC tried to cover (except that 0 runtime overhead). However, you get the option to use different DBMs in tests than in production (pg in prod, sqlite in tests), which is a huge benefit for a lot of people. sequelts was designed to work with sqlite only. And it's not a hack.
-
Flyweight: An ORM for SQLite
The only thing I can imagine where this would be useful is when you don't have control about what DB is being used, for example, when building a product that should be compatible with Postgres and MariaDB (and each is getting used). However, in the age of containerization, this isn't a big problem any more.
In some ORMs, I need to create types that the result of a query containing JOINs is mapped to. Others don't support them _at all_. In TypeORM, there is a query builder which forces you to put in _some_ SQL for things like "WHERE a in (b, c)".
I created a proof of concept of a different approach: Just embrace SQL and provide static typing based on the query. The return type of a query is whatever that thing is that the query returns in the context of the database schema. It's possible to do in TypeScript, by parsing the SQL query at development time:
https://github.com/nikeee/sequelts
One benefit is that it does not need any runtime code, as it's just a type layer over SQL. You don't have to rely on some type-metadata that TypeScript emits. That's why it also works with JavaScript only.
-
Deepkit – High-Performance TypeScript Framework
I don't like ORMs that use runtime types either. Most of the time, I want to write raw SQL.
So as an experiment, I created a library that statically types raw SQL:
https://github.com/nikeee/sequelts
The idea is to parse the SQL queries using TS's type system. The parsed query is combined with the database schema and therefore, we know what type the query will return.
This is especially useful due to TS's structural type system.
What are some alternatives?
Dapper.FSharp - Lightweight F# extension for StackOverflow Dapper with support for MSSQL, MySQL, PostgreSQL, and SQLite
liveviewjs - LiveView-based library for reactive app development in NodeJS and Deno
SqlHydra - SqlHydra is a suite of NuGet packages for working with databases in F# including code generation tools and query expressions.
flyweight - An ORM for SQLite
Mondocks - An alternative way to interact with MongoDB databases from F# that allows you to use mongo-idiomatic constructs
kysely-codegen - Generate Kysely type definitions from your database.
Npgsql.FSharp - Thin F# wrapper around Npgsql, the PostgreSQL database driver for .NET
ts-sql - A SQL database implemented purely in TypeScript type annotations.
DustyTables - Thin F# API for SqlClient for easy data access to ms sql server with functional seasoning on top
assert-combinators - Functional assertion combinators.
tsql - Transact-SQL template combinators.
postgresql-typed - Haskell PostgreSQL library with compile-time type inference