In my ears that's just neglect? You assume your ORM does the basic data mapping right and don't verify it?

marcosdumay 5 days ago | parent | next [-]

> You assume your ORM does the basic data mapping right

You know, it should. There's no good reason for an ORM to ever fail at runtime due to mapping problems instead of compile time or start time. (Except, of course if you change it during the software's execution.)

	▲	Yokohiii 5 days ago \| parent [-]
		Why should a raw query fail?

▲

tossandthrow 5 days ago | parent | prev [-]

No? The difference is to verify it ones for the orm VS ones for every single place your query.

▲

Yokohiii 5 days ago | parent | next [-]

I have to respond here as I seemingly the depth limit is reached.

As you've mentioned graphql you probably comparing ORM in that sense to an traditional custom API with backed by raw sql. In a fair comparison both version would do the exactly same, require the same essential tests. Assuming more variations for the raw sql version is just assuming it does more or somehow does it badly in terms of architecture. Which is not a fair comparison.

	▲	tossandthrow 5 days ago \| parent [-]
		The orm represents deferred organization. Ie someone else is testing mapping and query generation for you. An example is prisma. Prisma has a team og engineers that work on optimizing query generation and provide a simple and intuitive api. Not using an orm forces you to take over that organization and test that extra complexity that goes into you code base. It might be merited if you get substantiel performance boosts - but I have not seen any reasonably modern orm where performance is the issue.

▲

Yokohiii 5 days ago | parent | prev [-]

A raw query doesn't has to be repeated in every place it's required. Not sure what your point is.

	▲	tossandthrow 5 days ago \| parent [-]
		You will have a bigger variety of queries hwne you don't use an orm - this puts a higher load on software testing to get the same level of reliability.