4 ms·

Have to say, if you like to do bare metal SQL, using the nice features of Postgres, working with this lib is a total Joy! No “fancy” and bleeding abstractions

Have to say, if you like to do bare metal SQL, using the nice features of Postgres, working with this lib is a total Joy! No “fancy” and bleeding abstractions like something like Prisma, not convoluted type annotations like other TS libs, no, just plain SQL statements in the best JavaScript way of doing it. I discovered learning to do Postgres a couple years ago, after getting sick of trying to hack Prisma, tried out several others, and after a couple minutes using this, i knew I wasn’t going back.

cultofmetatron 3y ago
I'd love to see a library like ecto (eilxir) for javascript. its easily the best toolkit for working with sql I've ever found. simple, powerful and easy to reason about
- jmondi 3y ago
  Curious what you think makes it better than other examples out there? How is it different than Active Record or Prisma?
  - cultofmetatron 3y ago
    the list would merit its own dedicated blog post but to highlight a few nice parts, ecto lets me write sql code in elixir. it does not try to wrap it all into objects but I do get schemas. so for instance I can create a schema `Player` which maps to a table "players" I can then get them via ``` from(p in Player) |> where([p], p.id in ^player_ids) |> select([p], p) |> Repo.all() ``` need to join with an association? ``` from(p in Player) |> join([p], s in assoc(p, :scores), as: :score) |> where([p], p.id in ^player_ids) |> preload([p, score: s], [score: s]) |> select([p], p) |> Repo.all() ``` this gets me all players with their scores. need to get the sum of scores for all players? ``` from(p in Player) |> join([p], s in assoc(p, :scores), as: :score) |> where([p], p.id in ^player_ids) |> select([p], %{ player_id: p.id, score: sum(score.value) }) |> group_by([p, score: s], [p.id]) |> Repo.all() ``` as you can see, you can unwind this pretty fast to sql in your head. but you can also let the system just grab the kitchen sink when you jsut need to get somethign working fast. and its all very easy to modify and decuple. this is hardly exhaustive though, I could spend a day talking about ecto. I spent 8 years developing in nodejs but now I work exclusively in elixir. unless what you're doing is 90% done by existing libraries, its juts a better tool for building highly performant backends.
    - spion 3y ago
      Have you tried drizzle? https://orm.drizzle.team/docs/select#aggregations https://orm.drizzle.team/docs/select#aggregations (note: it produces type-safe results too)
      - KRAKRISMOTT 3y ago
        Their migrations tool is proprietary and not open-source. The project is basically an open source bait and switch riding off the edge computing hype (since prisma and other major JS ORMs have poor support for edge environments).
        spion 3y ago
        You don't need to use drizzle migrations. There are much better migration tools.
    - invaliduser 3y ago
      This is probably great to use, but it also highlights in comparison the beautiful simplicity of SQL. Doing something simple is hard, and SQL is so simple that I think most people find little value to abstractions built on it.
      - kiliancs 3y ago
        There are different valid ways to produce these queries, some of which might be less composable but simpler: https://hexdocs.pm/ecto/Ecto.Query.html https://hexdocs.pm/ecto/Ecto.Query.html
  - esafak 3y ago
    prisma appears to have a transaction problem. https://github.com/prisma/prisma/discussions/12715 https://github.com/prisma/prisma/discussions/12715
    - misnome 3y ago
      Wow, a project describing itself as a “Next generation ORM” that… doesn’t do joins, with no way to optimise queries. Perhaps they mean “Next generation” as in, the 1987 TV series sense. Which would still be a long time after the concept of joins…
      - djbusby 3y ago
        To boldly go where the problem was solved ages ago
      - pstuart 3y ago
        There's One Weird Trick™ in managing joins in this case -- create views that implement the joins and then just treat it as yet another table. Bonus feature is creating a consistent way of working with that relation using native DB tools. ;-)
        cultofmetatron 3y ago
        that works great till your database gets big. Then you will watch your memory use skyrocket to perform joins into that view and it will F@#$@# your shit up. eventually it will take so much time to construct your view table that you'll tiemout your connection pool. to be clear, dont' use views in production queries. you WILL regret it. source: made this mistake.
    - meekaaku 3y ago
      Really wow. Such a basic feature should be available in beta version
- cpursley 3y ago
  If you like ecto but want something closer to the metal (no need to define type mapping), then check out https://github.com/robconery/moebius https://github.com/robconery/moebius I vastly prefer it over ecto, and ecto is awesome.
FpUser 3y ago
Was never fond of layers above SQL either. One would have to pry SQL from my cold dead fingers
- Rapzid 3y ago
  I love layers above sql because it can make a lot of domain logic nice to model. But dropping down when it it makes sense and finding a rock solid foundation is nice too. <3 Entity Framework Core but also love the new interfaces that let me cast a db connection to Npgsql connection and use its advanced features and raw performance. It would be great if postgresjs could underpin Knex and MikroOrm.
ttyyzz 3y ago
What made you dislike Prismas raw query feature?
ianberdin 3y ago
Yea, it is a totally fan to work with this code after a responsible developer leaves a company. No types, no annotations, no abstractions, no migrations, just plain SQL.
- porsager 3y ago
  I can't read if you're being snarky or if you are being earnest. If snarky, is this based on something that actually happened to you? If so, I would love to hear how that actually went about, and what it is you are unable to grasp when things aren't bogged down by complexity? If earnest, I'm glad more people prefer code that isn't littered with premature abstractions, redundant types, and useless comments expressing what can be more clearly read in the actual code.

cultofmetatron 3y ago

I'd love to see a library like ecto (eilxir) for javascript. its easily the best toolkit for working with sql I've ever found. simple, powerful and easy to reason about

jmondi 3y ago
Curious what you think makes it better than other examples out there? How is it different than Active Record or Prisma?
- cultofmetatron 3y ago
  the list would merit its own dedicated blog post but to highlight a few nice parts, ecto lets me write sql code in elixir. it does not try to wrap it all into objects but I do get schemas. so for instance I can create a schema `Player` which maps to a table "players" I can then get them via ``` from(p in Player) |> where([p], p.id in ^player_ids) |> select([p], p) |> Repo.all() ``` need to join with an association? ``` from(p in Player) |> join([p], s in assoc(p, :scores), as: :score) |> where([p], p.id in ^player_ids) |> preload([p, score: s], [score: s]) |> select([p], p) |> Repo.all() ``` this gets me all players with their scores. need to get the sum of scores for all players? ``` from(p in Player) |> join([p], s in assoc(p, :scores), as: :score) |> where([p], p.id in ^player_ids) |> select([p], %{ player_id: p.id, score: sum(score.value) }) |> group_by([p, score: s], [p.id]) |> Repo.all() ``` as you can see, you can unwind this pretty fast to sql in your head. but you can also let the system just grab the kitchen sink when you jsut need to get somethign working fast. and its all very easy to modify and decuple. this is hardly exhaustive though, I could spend a day talking about ecto. I spent 8 years developing in nodejs but now I work exclusively in elixir. unless what you're doing is 90% done by existing libraries, its juts a better tool for building highly performant backends.
  - spion 3y ago
    Have you tried drizzle? https://orm.drizzle.team/docs/select#aggregations https://orm.drizzle.team/docs/select#aggregations (note: it produces type-safe results too)
    - KRAKRISMOTT 3y ago
      Their migrations tool is proprietary and not open-source. The project is basically an open source bait and switch riding off the edge computing hype (since prisma and other major JS ORMs have poor support for edge environments).
      - spion 3y ago
        You don't need to use drizzle migrations. There are much better migration tools.
  - invaliduser 3y ago
    This is probably great to use, but it also highlights in comparison the beautiful simplicity of SQL. Doing something simple is hard, and SQL is so simple that I think most people find little value to abstractions built on it.
    - kiliancs 3y ago
      There are different valid ways to produce these queries, some of which might be less composable but simpler: https://hexdocs.pm/ecto/Ecto.Query.html https://hexdocs.pm/ecto/Ecto.Query.html
- esafak 3y ago
  prisma appears to have a transaction problem. https://github.com/prisma/prisma/discussions/12715 https://github.com/prisma/prisma/discussions/12715
  - misnome 3y ago
    Wow, a project describing itself as a “Next generation ORM” that… doesn’t do joins, with no way to optimise queries. Perhaps they mean “Next generation” as in, the 1987 TV series sense. Which would still be a long time after the concept of joins…
    - djbusby 3y ago
      To boldly go where the problem was solved ages ago
    - pstuart 3y ago
      There's One Weird Trick™ in managing joins in this case -- create views that implement the joins and then just treat it as yet another table. Bonus feature is creating a consistent way of working with that relation using native DB tools. ;-)
      - cultofmetatron 3y ago
        that works great till your database gets big. Then you will watch your memory use skyrocket to perform joins into that view and it will F@#$@# your shit up. eventually it will take so much time to construct your view table that you'll tiemout your connection pool. to be clear, dont' use views in production queries. you WILL regret it. source: made this mistake.
  - meekaaku 3y ago
    Really wow. Such a basic feature should be available in beta version
cpursley 3y ago
If you like ecto but want something closer to the metal (no need to define type mapping), then check out https://github.com/robconery/moebius https://github.com/robconery/moebius I vastly prefer it over ecto, and ecto is awesome.

FpUser 3y ago

Was never fond of layers above SQL either. One would have to pry SQL from my cold dead fingers

Rapzid 3y ago
I love layers above sql because it can make a lot of domain logic nice to model. But dropping down when it it makes sense and finding a rock solid foundation is nice too. <3 Entity Framework Core but also love the new interfaces that let me cast a db connection to Npgsql connection and use its advanced features and raw performance. It would be great if postgresjs could underpin Knex and MikroOrm.

ttyyzz 3y ago

What made you dislike Prismas raw query feature?

ianberdin 3y ago

Yea, it is a totally fan to work with this code after a responsible developer leaves a company. No types, no annotations, no abstractions, no migrations, just plain SQL.

porsager 3y ago
I can't read if you're being snarky or if you are being earnest. If snarky, is this based on something that actually happened to you? If so, I would love to hear how that actually went about, and what it is you are unable to grasp when things aren't bogged down by complexity? If earnest, I'm glad more people prefer code that isn't littered with premature abstractions, redundant types, and useless comments expressing what can be more clearly read in the actual code.