4 ms·

I find that most of the production features you mentioned are actually more difficult using a fat ORM. How many hours have i wasted figuring out how i can writ

by exevp 6y ago

I find that most of the production features you mentioned are actually more difficult using a fat ORM. How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL ... Plus i have a hard time seeing the benefit of Prisma. You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise so it feels like a complete waste of time to come up with the DSL in the first place. I can only imagine the hard time you have once you first have to break out of the frameworks cage because you hit a case which isn't easily solved by the framework itself ...

midrus 6y ago
>I find that most of the production features you mentioned are actually more difficult using a fat ORM. Prisma doesn't look like the traditional ORM to me. In fact, the library from the OP uses classes, which prisma and Knex do not use > How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins.
- exevp 6y ago
  > In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins. That's true, although the most frustrating percent of the cases :) I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction. MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries. KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.
  - Seb-C 6y ago
    > expanding lists of column names I am not sure about what do you mean here? > dealing with casing (snake_case to camelCase) This is one of the opinionated parts of kiss-orm I guess, because I specifically do not want to implement this. I think having consistency in the naming of the properties/columns is more important. I would rather break the naming convention by having snake_case properties than automagically rename properties.
    - exevp 6y ago
      > I am not sure about what do you mean here? Given i have defined the columns of interest in my data objects anyways... class User { name = null; email = null; } ... i wouldn't necessarily have to repeat them when writing my SQL: sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users` Of course using a better helper function. There's a few repetitive tasks when writing SQL where don't necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.
      - Seb-C 6y ago
        I see what you mean. Indeed, more helpers would be ... helpful I guess, but for now I only implement what I really need and feel like is necessary. For your specific example, what is wrong with `SELECT *`?
2color 6y ago
Thanks for sharing your thoughts about Prisma. > Plus i have a hard time seeing the benefit of Prisma Prisma is supposed to improve your productivity and confidence when working with a database. It does so with a strong focus on type safety. Most ORMs and query builders in the Node.js/TypeScript ecosystem do not provide the level of type safety that Prisma does. For example in a blog with users and posts (1:n) querying a user and related posts looks as follows: const user = await prisma.user.findOne({ where: { id: 1 }, include: { posts: true } }) console.log(user.posts) The user object will have the correct TypeScript type, including the posts object. If you remove the include object from the findOne call and avoid fetching related posts, the user's type will change. This approach to type safety helps in catching many problems at build time. It's possible because of the Prisma schema, which is the single source of truth for both the database schema and the generated TypeScript client. You don't have the burden of mapping between the database schema and the types in their application. Besides that, it's a declarative and concise description for the database schema and is database agnostic. The type safety features come at "zero-cost" because you don't have to write all the TypeScript types and mappings to the database. Prisma generates the TypeScript client from your Prisma schema. > You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise The Prisma schema is actually fundamentally different to JS or TS because it's declarative rather than imperative.
- joshmanders 6y ago
  I have this same stuff in TypeORM but don't have the DSL issues that exevp mentioned..
  - 2color 6y ago
    I think this article does a good job of comparing the two if you're familiar with TypeORM: https://medium.com/better-programming/prisma-vs-typeorm-60d02f9dac64 https://medium.com/better-programming/prisma-vs-typeorm-60d0... which compares the two. Most of exevp's comment about the Prisma schema are a non-issue given an understanding of the value it provides. But I can understand the reluctance to learn yet another DSL. But in my experience, if you've worked with relational databases, it's a breath of fresh air to be able to define your database schema with it.
christophilus 6y ago
> How many hours...? Plenty. Just this week, I spent the better part of a day trying to figure out why customers were losing data. Turns out it was a bad ActiveRecord polymorphic definition that was written over 4 years ago, but which only started surfacing recently due to overlapping ids in the relevant tables. When I looked at the generated SQL, the bug was obvious. But looking only at the ActiveRecord definitions, the bug was nonobvious. Give me plain SQL all day everyday. I’m tired of ORMs.

by exevp 6y ago

midrus 6y ago

>I find that most of the production features you mentioned are actually more difficult using a fat ORM. Prisma doesn't look like the traditional ORM to me. In fact, the library from the OP uses classes, which prisma and Knex do not use > How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins.

exevp 6y ago
> In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins. That's true, although the most frustrating percent of the cases :) I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction. MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries. KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.
- Seb-C 6y ago
  > expanding lists of column names I am not sure about what do you mean here? > dealing with casing (snake_case to camelCase) This is one of the opinionated parts of kiss-orm I guess, because I specifically do not want to implement this. I think having consistency in the naming of the properties/columns is more important. I would rather break the naming convention by having snake_case properties than automagically rename properties.
  - exevp 6y ago
    > I am not sure about what do you mean here? Given i have defined the columns of interest in my data objects anyways... class User { name = null; email = null; } ... i wouldn't necessarily have to repeat them when writing my SQL: sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users` Of course using a better helper function. There's a few repetitive tasks when writing SQL where don't necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.
    - Seb-C 6y ago
      I see what you mean. Indeed, more helpers would be ... helpful I guess, but for now I only implement what I really need and feel like is necessary. For your specific example, what is wrong with `SELECT *`?

2color 6y ago

Thanks for sharing your thoughts about Prisma. > Plus i have a hard time seeing the benefit of Prisma Prisma is supposed to improve your productivity and confidence when working with a database. It does so with a strong focus on type safety. Most ORMs and query builders in the Node.js/TypeScript ecosystem do not provide the level of type safety that Prisma does. For example in a blog with users and posts (1:n) querying a user and related posts looks as follows: const user = await prisma.user.findOne({ where: { id: 1 }, include: { posts: true } }) console.log(user.posts) The user object will have the correct TypeScript type, including the posts object. If you remove the include object from the findOne call and avoid fetching related posts, the user's type will change. This approach to type safety helps in catching many problems at build time. It's possible because of the Prisma schema, which is the single source of truth for both the database schema and the generated TypeScript client. You don't have the burden of mapping between the database schema and the types in their application. Besides that, it's a declarative and concise description for the database schema and is database agnostic. The type safety features come at "zero-cost" because you don't have to write all the TypeScript types and mappings to the database. Prisma generates the TypeScript client from your Prisma schema. > You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise The Prisma schema is actually fundamentally different to JS or TS because it's declarative rather than imperative.

joshmanders 6y ago
I have this same stuff in TypeORM but don't have the DSL issues that exevp mentioned..
- 2color 6y ago
  I think this article does a good job of comparing the two if you're familiar with TypeORM: https://medium.com/better-programming/prisma-vs-typeorm-60d02f9dac64 https://medium.com/better-programming/prisma-vs-typeorm-60d0... which compares the two. Most of exevp's comment about the Prisma schema are a non-issue given an understanding of the value it provides. But I can understand the reluctance to learn yet another DSL. But in my experience, if you've worked with relational databases, it's a breath of fresh air to be able to define your database schema with it.

christophilus 6y ago

> How many hours...? Plenty. Just this week, I spent the better part of a day trying to figure out why customers were losing data. Turns out it was a bad ActiveRecord polymorphic definition that was written over 4 years ago, but which only started surfacing recently due to overlapping ids in the relevant tables. When I looked at the generated SQL, the bug was obvious. But looking only at the ActiveRecord definitions, the bug was nonobvious. Give me plain SQL all day everyday. I’m tired of ORMs.