3 ms·

Why is it such a 'one vs other' argument? This is like arguing against levels of APIs, a completely moot argument without proper context for usage.'Wrapping' do

Why is it such a 'one vs other' argument? This is like arguing against levels of APIs, a completely moot argument without proper context for usage.'Wrapping' doesn't prohibit you to go 'lower' if you want.

lugg 8y ago
Why is it one vs other? It's not, you can run them both. The question is why you would. What does an ORM solve for you? This is the only mapping I need from an ORM: result = (object) row row = (array) result SQL does everything an ORM does better. I'm not sure how you can call moving from a low level programming language to a domain specific language like SQL "going lower". It's not and ORMs are usually so bad they're a regression in what you can do. Also, when was the last time a change to the SQL spec broke your app?what about the last times you had to migrate ORM code?
- ken 8y ago
  > Also, when was the last time a change to the SQL spec broke your app?what about the last times you had to migrate ORM code? That's kind of an arbitrary categorization. An ORM is just a library. If you asked me when the last time I had to update my code because a library changed interfaces, I'd have an answer for you (less than a month ago, I'm sure). I'm not going to stop using libraries, though. I've had to update my programs several times because my compiler was updated, too. That may make me choosier in the future about which compiler I pick, but I'm not going to stop using compilers altogether.
cmiles74 8y ago
I think things have very much moved away from the "one vs. the other" stance. Back in the late 90's, I think people really did think that they could spend time on an ORM tool and never have to think about the database. In my own work, the ORM is there for lots of boring stuff, like fetch the data and push it into an edit form and then push the contents of the edit form back into the database. When it comes to q query of any consequence I end up writing SQL and then presenting a data set to the ORM, something that it can understand. Maybe it's my age, but I'm still not a big stored procedure guy. But you look at some of the interesting things you can do with SQL, it seems silly to try and interact with it only through someone else's ORM tool.
HelloNurse 8y ago
The arguments is against a specific level of API that is particularly bad. Expecting simple means to obtain objects out of tables is unreasonable, and attempts to that purpose must cheat one way or the other; in the opposite direction pretending that a database can offer "persistence" for objects is naive and highly constraining.

lugg 8y ago

Why is it one vs other? It's not, you can run them both. The question is why you would. What does an ORM solve for you? This is the only mapping I need from an ORM: result = (object) row row = (array) result SQL does everything an ORM does better. I'm not sure how you can call moving from a low level programming language to a domain specific language like SQL "going lower". It's not and ORMs are usually so bad they're a regression in what you can do. Also, when was the last time a change to the SQL spec broke your app?what about the last times you had to migrate ORM code?

ken 8y ago
> Also, when was the last time a change to the SQL spec broke your app?what about the last times you had to migrate ORM code? That's kind of an arbitrary categorization. An ORM is just a library. If you asked me when the last time I had to update my code because a library changed interfaces, I'd have an answer for you (less than a month ago, I'm sure). I'm not going to stop using libraries, though. I've had to update my programs several times because my compiler was updated, too. That may make me choosier in the future about which compiler I pick, but I'm not going to stop using compilers altogether.

cmiles74 8y ago

I think things have very much moved away from the "one vs. the other" stance. Back in the late 90's, I think people really did think that they could spend time on an ORM tool and never have to think about the database. In my own work, the ORM is there for lots of boring stuff, like fetch the data and push it into an edit form and then push the contents of the edit form back into the database. When it comes to q query of any consequence I end up writing SQL and then presenting a data set to the ORM, something that it can understand. Maybe it's my age, but I'm still not a big stored procedure guy. But you look at some of the interesting things you can do with SQL, it seems silly to try and interact with it only through someone else's ORM tool.

HelloNurse 8y ago

The arguments is against a specific level of API that is particularly bad. Expecting simple means to obtain objects out of tables is unreasonable, and attempts to that purpose must cheat one way or the other; in the opposite direction pretending that a database can offer "persistence" for objects is naive and highly constraining.