Hacker News Reader

Comment by xakerbox | Hacker News Reader

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 :(

View on HN

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