Headless ORM and batteries included ORM? | Hacker News Reader

Headless ORM and batteries included ORM?

11 pointsalexblokh6 comments

What would be the difference? What features make ORM batteries included?

I think the deviation had happened and due to a massive amount of different ORMs out there - there's been a shift in ORM perception. For some reason people don't expect ORM to be an "Object Relational Mapping" in the domain of SQL databases. I try to understand why.. Also people are expecting ORM to abstract away from SQL for whatever reason instead of embracing SQL.

Did you try to code Joins on TypeORM? I've bad news for you bro... It's no abstraction between 'SQL' and ORM... It's a different galaxy in mind of creators of that 'revolutionary ORM'.

I dream, that someday I will not spend hours and hours on understanding how to convert my SQL query to ORM. And I don't want to spend hours and hours on understanding that process — clients pay for time, they don't pay for tools that you use in your developing process.

Understandable and clear process of joins and simplified table's description entity process... But there's no 'all in one' package for that stuff still exist :(

what would be the line between headless and headfull ORM for you?

does it lay before or after schema declaration in code in the domain of ORM does it influenced be either ORM is abstracting SQL away from you or it is abstracting on top of SQL

When I look at SQL query, I understand it. This syntax even cry: SELECT, FROM, WHERE, AND, INNER, LEFT JOIN — use this words and get success. Nothing else. But typical ORM provides you a lot of 'underground process' — they're trying to simplify process, but as result — as developer I need to spend time on understanding 'What does that guys mean when then hide simple query from my eyes'.

Headfull ORM in my mind — it's ORM with clear syntax, typing and minimal possibility simply DESCRIBE your table and CRUD with any entities in that table with well-known SQL-syntax.

I truly believe that you should spend 0 time migrating SQL query to code. When you design data persistence - you do it in SQL domain, when you solve business demands in data domain - you do it in SQL. When you know how to solve problem in SQL - you should straight away know how to do it with ORM ORM should embrace SQL and not hide it under the carpet. By doing that many other ORMs supply you with hidden consequences

Reply on news.ycombinator.com