Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To be fair, a lot of those tools have that one weird caveat you need to know, and are also strongly dependent on your dialect.

For example there's an aggregate function in DB/2, LISTAGG, that joins strings... the caveat being that if they get too long, the query blows up. It's in OracleSQL too, which has a syntax where you can tell it to truncate the string.

SELECT, INSERT, UPDATE, DELETE work more or less the same whether you're on MariaDB, Postgres, DB/2, OracleSQL, etc.



As opposed to the dizzying array of ORMs that all have multiple caveats you need to know and utterly incompatible in fundamental ways between each other?

Folks go on about how they're "stuck" with a single dialect of SQL but completely ignore how utterly impossible it is to switch ORMs without a full app rewrite. And ORMs are all language-specific, so if you have two different app clients in different languages, you can't always share even basic API access patterns.

Got a Java Spring app alongside a Django app? Good luck!


IoC (not just interfaces, not just DI) should avoid this.

Inject me an object that gets people objects that meet an interface (ok might need to be async) and you can switch out how that is done later.

But it is more boilerplate


Well yeah, I do think there is a fundamental difference given the DBMS is effectively hidden in this scenario, whereas the ORM is not.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: