Ask HN: Is there still ORM hate these days?

[kw123]

If you prefer SQL, what are the ideal features you wish to have? Like editing SQL in a SQL editor, having object-relational data transformation abstracted away, etc.

If you don't like SQL, do you prefer to have only DAO/repository interface in your application and defer the implementation to backend or even to some other people?

Overall, do you think that we need a "better" solution than ORM? For example, something that is simple but allows us to handle complex objects. I am working on a solution for relational database access and trying to get directions. Your comments are really appreciated.

[sandreas]

> Is there still ORM hate these days?

I would say yes, but that is not a qualifier... there is hate for nearly everything, probably even unicorns and rainbows. However, ORM hate sometimes is reasonable.

> what are the ideal features you wish to have?

Most likely LAYERS.

  RAW SQL - I want to be able to execute raw queries
  ABSTRACTION - I don't want to take care of all the different DMBS and Prepared statements all the time
  QUERY BUILDER - It's neat to have a fluent interface query builder to prevent string manipulation for queries
  REPOSITORIES - I would like to have some good basic classes for the repository pattern
  ORM - Sometimes I just do CRUD and code first ORM is often helpful to rollout db structure
  OBJECT QUERY LANGUAGE - In some edge cases it would be nice to query objects

Best case scenario would be to have all these as different lightweight libraries building on top of each other without being to tightly coupled. In PHP there is Doctrine DBAL and Doctrine ORM, in C# there is SqlKata and Entity Framework, but I did not find a stack like described above where you can pull each of these LAYERS separately.

For an sql editor I would wish an autocomplete code editor with syntax highlight, auto formatting, auto-complete, query history. Globally scriptable variables including a vault for secrets (e.g. select {datefields.expand()} from users) would also be cool (similar to Postman).

[shujutech]

The current ORM do not map seamlessly to OO. Please check this instead:

- http://shujutech.mywire.org/corporation?goto=ormj

- https://github.com/shujutech/StORMi

We're looking for SQL parser expert to help us place in the like such as OQL/HQL into StORMi. Please help!

[halabooda]

As I noticed in Golang-comunity ORM is very hated, because used simple solutions. At the same time for startups ORM is too much, because spending time on backend development is very expensive, considering the probability of success... Active Record and RAD frameworks can reduce development costs, but tools like Firebase/Supabase allow for even faster and cheaper development...

[fwungy]

SQL seems like a perfect candidate for AI support.

> Join the tables foo and bar on bar_id and bar and baz on baz_id and select quip that begins with 'it' or ends with 'qu' but does not have numbers, for oracle, using date format mm/dd/yyyy.

[tonnyxu]

We tried with ChatGPT, if you throw enough context(Database Schema) to it, it will be able to find the relationship in the tables and generate the join correctly. And for date format, yeah, if you don't specify it, you won't get what you want in some cases.

[jaredsohn]

AI support also works great for generating code that uses ORMs.

[JodieBenitez]

I like SQL. I also like a good ORM. A good ORM is one that won't get in your way once you need to go SQL.

[revskill]

ORM idea is good.

The problem is libraries is bad, really bad.