Compare and contrast against ts-typed-sql

[AnyhowStep]

trafficstars

I actually had this as a TODO in the README, https://github.com/hediet/ts-typed-sql

But since @Ciantic has explicitly opened an issue for it on https://github.com/AnyhowStep/typed-orm , I am opening one here, too.

Original issue, https://github.com/AnyhowStep/typed-orm/issues/9

---

typed-orm is actually abandoned (although fully functional for MySQL 5.7). This project is its successor. However, this is still a work-in-progress.

I've been busy adding a lot of tests, to ensure predictable behaviour across MySQL and SQLite (for now).

---

Although it is a work-in-progress, and not yet published on npm, https://github.com/AnyhowStep/tsql-mysql-5.7 is actually fully functional

I just haven't taken the time for documentation, publishing, more tests, etc.

[Ciantic]

Edit Moved my comment from the old repo to here.

Glad to see you are still trying to solve this! I starred the new repo. I haven't yet tried to read how you are trying to solve this.

My point is that the problem you are trying to solve is hard. It requires deep understanding of types to do right, mapping between two languages is not easy. Otherwise the solution ends up being "stringly typed" (derogatory term) like the popular typeorm.

In my opinion Hediet's attempt, so far, is best I've seen with TypeScript. Of course with other languages like in Haskell they have found a better solutions already that more correctly maps to SQL.

The ideal end result is flexible, but strict enough that user can be somewhat sure that "if the Query built with ORM type checks in the editor, it's correct SQL".

P.S. even though I'm interested in this, I'm not an expert at solving this.

[AnyhowStep]

If you clone this repo, npm install and look at the test/compile-time directory, you should see that this library protects you from a large class of errors, and also does more than ts-typed-sql (if I may toot my horn)

[AnyhowStep]

A sample from the compile time tests,

https://github.com/AnyhowStep/tsql/blob/master/test/compile-time/input/unified-query/inner-join/cannot-reference-outer-query-joins-in-on-clause.ts

And the expected compiler error from TS 3.5.1 https://github.com/AnyhowStep/tsql/blob/master/test/compile-time/expected-output/unified-query/inner-join/cannot-reference-outer-query-joins-in-on-clause.ts.errors

messageText": "Property '__compileError' is missing in type 'ExprImpl<boolean, IUsedRef<{ readonly myTable: { readonly myTableId: bigint; }; readonly myTable3: { readonly myTable3Id: bigint; }; }>, false>' but required in type 'CompileError<["ON clause must not reference outer query tables", "myTable"]>'.",

[Ciantic]

I've been reading your code a while. This seems really good!

I hope you can "package and paint" this nicely for the all JavaScripters out there who don't understand or care about types.

The main problem with these sole attempts at solving this is the burn out, it's no wonder that Microsoft has entire team working on ORM.

[AnyhowStep]

I'll worry about public relations like type-safety evangelism when I feel like I have a more solid offering =P

I try to be aware of burnout and switch between different kinds of issues so I don't get too bored.

Writing all those tests and investigating all the edge cases was a pain after a while, and I'm not even done!

I'm actually taking a step back from writing tests for this library to work on a fixed point type library so I can emulate DECIMAL(p, s) for any SQLite JS library.

https://github.com/AnyhowStep/tsql/issues/28

I need the emulation so I can work on decimal data type tests for this library. I also never liked how SQLite lacked decimal support, in general.