3 ms·

> fixing bugs or adding workarounds for deficiencies in the SQL abstraction libraries and ORMs TBH I had same experience with all ORMs I have used sqlpp(c++),

by slezyr 8y ago

> fixing bugs or adding workarounds for deficiencies in the SQL abstraction libraries and ORMs TBH I had same experience with all ORMs I have used sqlpp(c++), odb(c++), diesel(rust).

sametmax 8y ago
ORM are one of those kind of libs where very few ones are great. Python has lots of them, and only SQLAlchemy can be considered of high quality. Not that Django's ORM, peewee or eloquent don't get the job done. But they only cover 80% of the use cases. SQLA gets you to 95%, and you bridge the five remaining percents with raw sql injected in the proper places for those rare projects where the extra is important. The cost of it is that it's a harder to use ORM, and a more verbose one. Which is why I generally use https://github.com/absent1706/sqlalchemy-mixins https://github.com/absent1706/sqlalchemy-mixins to make things easier. What's more, ORM for languages like c++ or Rust have it extra hard as they are used from a low level tech while SQL is quite high level and easy to manipulate. It's hence attractive to use it directly. If you use PHP, Ruby or Python, SQL doesn't seem that big of a gain anymore for the simple operations. Now diesel is quite young, and the rust ecosystem has proven to be moving not only fast, but generally in a sane direction, so I wouldn't count it out just yet. However, I've yet to find an even acceptable JS ORM. Not only do they fail to provide any decent operation beyond simple ones, but they have such poor introspection capabilities that they can't be used to create an ecosystem around them. Which is, after all, __the main point of an ORM__. Avoiding to write SQL is definitively NOT the most important feature of an ORM. The critical one is having a common API you can build upon to create form generators, auth systems, data validation units, serializers, automatic UI, etc. Without this, the case for using an ORM is way weaker.
lucio 8y ago
This article could be titled ORM considered harmful (2006) http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
- ris 8y ago
  There's a lot of hatred for ORMs that floats around but most of the ire seems to revolve around the cases where the ORM's flexibility doesn't allow it to expose the power of the underlying database properly. But people often fail to note how few and far between these examples are and how the vast majority of an app's queries tend to be dumb & boring and handled extremely competently by the ORM. Contrast this with the number of dumb typos & sql mistakes through verbosity that the ORM has saved. Don't get distracted by the 1 or 2 cases per app.

by slezyr 8y ago

> fixing bugs or adding workarounds for deficiencies in the SQL abstraction libraries and ORMs TBH I had same experience with all ORMs I have used sqlpp(c++), odb(c++), diesel(rust).

sametmax 8y ago

ORM are one of those kind of libs where very few ones are great. Python has lots of them, and only SQLAlchemy can be considered of high quality. Not that Django's ORM, peewee or eloquent don't get the job done. But they only cover 80% of the use cases. SQLA gets you to 95%, and you bridge the five remaining percents with raw sql injected in the proper places for those rare projects where the extra is important. The cost of it is that it's a harder to use ORM, and a more verbose one. Which is why I generally use https://github.com/absent1706/sqlalchemy-mixins https://github.com/absent1706/sqlalchemy-mixins to make things easier. What's more, ORM for languages like c++ or Rust have it extra hard as they are used from a low level tech while SQL is quite high level and easy to manipulate. It's hence attractive to use it directly. If you use PHP, Ruby or Python, SQL doesn't seem that big of a gain anymore for the simple operations. Now diesel is quite young, and the rust ecosystem has proven to be moving not only fast, but generally in a sane direction, so I wouldn't count it out just yet. However, I've yet to find an even acceptable JS ORM. Not only do they fail to provide any decent operation beyond simple ones, but they have such poor introspection capabilities that they can't be used to create an ecosystem around them. Which is, after all, __the main point of an ORM__. Avoiding to write SQL is definitively NOT the most important feature of an ORM. The critical one is having a common API you can build upon to create form generators, auth systems, data validation units, serializers, automatic UI, etc. Without this, the case for using an ORM is way weaker.

lucio 8y ago

This article could be titled ORM considered harmful (2006) http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

ris 8y ago
There's a lot of hatred for ORMs that floats around but most of the ire seems to revolve around the cases where the ORM's flexibility doesn't allow it to expose the power of the underlying database properly. But people often fail to note how few and far between these examples are and how the vast majority of an app's queries tend to be dumb & boring and handled extremely competently by the ORM. Contrast this with the number of dumb typos & sql mistakes through verbosity that the ORM has saved. Don't get distracted by the 1 or 2 cases per app.