How about shared columns library?

[romeerez]

Hey guys, maybe you remember me - I got in touch with you at the beginning of the summer, and thought that maybe I could participate somehow in ORM development, but jumped off because had a different vision and wanted to create my own ORM.

And I've made it, and here is a my columns module.

I know, you will say that you want to develop your own to better match your specific needs, but just think about it for a bit: what if we move the columns module into a separate library and develop it together, and use it by two different ORMs?

Here are features I have and it looks like drizzle ORM columns don't have:

• columns are not nullable by default. In drizzle ORM a column has a method .notNull() so it looks like nullable by default, but TS type doesn't include null, so it seems to be a bug.
• table schema can be converted to a Zod schema to use for validations. For example: t.number().min(1).max(10). Here are the docs for it
• json column accepts a schema that is compatible with Zod, here are docs
• each column has a method to be converted to a code, so I have a code generator (in progress). I know this is not needed in Drizzle, but in my ORM it allows to generate models from running migrations.
• not implemented yet, but soon, I'm going to implement a feature like pull in Prisma, so people who already have a database with probably a different ORM could just run a command and generate both models and migrations to switch to your ORM, instead of manually writing 100500 models. This feature also relies on the ability to generate code from column schema.
• columns have special methods like .parse and .encode. This allows customized data parsing, so it can be configured to return a timestamp as a string, as an epoch number, or as a Date object, as the user wishes it to be.
• added all types from Postgres docs.
• test factories: this lib generates objects with fake data for testing purposes, also relies on the columns schema.
• I thought it to be a bright idea to require min and max for the text field. We, developers, never think about it until someone submits a text of a gazillion size or empty. So my text field will remind setting the bounds.
• everything is tested very well, 95% of test coverage is a real number. In Drizzle ORM it's not tested properly, sorry to say this, but copying this schema from quickstart results in TS error.

Currently, my columns are targetted for Postgres only, but if in case if you agree to integrate my columns and cooperate on their development, I'll do my best to cover MySQL and SQLite too.

I'd be happy if part of my work will be used on your real projects, and your work would benefit from it

Docs could be hosted on a separate site

[AlexBlokh]

hey, @romeerez
thanks for your interest in DrizzleORM and reaching out on potential collaboration

1. Nullability is mirrored from a particular database default behaviour. All non not null fields are nullable for both select and insert type infers. If you're referencing serial primary key it is never null for select and can be undefined for insert, which is exactly how it is now and it's type tested.
2. we already have a beta zod module for zod schema generation from table schemas
3. we intentionally does not integrate core of ORM to any external library, so any validations with or without zod should be done elsewhere
4. --
5. we already have introspect command in drizzle-kit to pull schema from database and convert it to our ts schema
6. for all database native datatypes we have a config for you to choose you want it as date or string, or as number or bigint. For everything else we have a way to build your own custom datatypes - see here
7. we already support multiple dialects and continue implementing new ones. We intentionally decided to implement each dialect as a separate module which lets us have best in class support for everything that a particular database api provides.
8. so far we didn't do anything custom for user, cause we're a thin layer on top of SQL, so however you'd test you raw sql queries - you can do it the same way with Drizzle ORM
9. that is definitely not a datalayer level validation and should be done partially on ingress proxy lvl, partially on app http server level and then on API level
10. Thank you for the feedback, I've fixed them. Feel free to report them as issues on our github page. So far we have 331 tests and we're constantly adding new ones and aiming to cover all the possible and impossible cases!

So far I don't see how we can benefit by switching to an external column builder libraries, we have zero problems with ours so far and it would be a massive workload for us which will definitely lead to a massive variety of problems to solve, yet again - thanks for your interest and feedback! Maybe some day we'll find a way to collaborate on something, we're always open to that!

[AndriiSherman]

Yes, you are right. It's possible null and TS will show you an error

[romeerez]

Interesting, okay, that's something with my setup

[romeerez]

Perhaps you're using nightly version, mine is ^0.16.0

[AndriiSherman]

1. Make sure you have "strictNullChecks": true in your tsconfig.json
2. Replace 3 line from import { drizzle } from "drizzle-orm-pg/postgres.js"; to import { drizzle } from "drizzle-orm-pg/node";. You've tried to use pg driver Pool for postgres.js driver connection

[romeerez]

Make sure you have "strictNullChecks": true in your tsconfig.json

That's it, no problems with the drizzle orm