3 ms·

> and still be using an enormous amount of automation to deal with the database drivers and moving data between your objects and rows I've found I would genera

by jpc0 3y ago

> and still be using an enormous amount of automation to deal with the database drivers and moving data between your objects and rows I've found I would generally only need the handling of database drivers and query building since I'm already writing a validation layer and to add data marshalling to that is pretty trivial. Likewise practicing YAGNI, what is the chances I need multiple database drivers for different databases, it's extremely unlikely that I'm going to be chopping and changing between different databases so I'm really only writing that code once. I would argue to start with writing the basic SQL queries and adding an ORM later when you know you actually need it. It's much easier to onboard someone into pure python code + a db driver vs having to onboard someone to SQLAlchemy, since it is quite a complex piece of software, necessarily complex for what it is trying to achieve but if you don't need it it's not a good fit.

jacurtis 3y ago
> I would argue to start with writing the basic SQL queries and adding an ORM later when you know you actually need it. I think you missed the point of the parent comment, which is that ORM's are not about writing SQL queries (although they do that). But ORMs are about moving data around, transforming it from rows and columns into meaningful objects in the project's language and data model. As the parent comment suggested, if you are dying to write your own SQL (which does often happen as queries get more complex and don't fit into ORM language model) then you can write raw SQL but still let the ORM do the heavy lifting so you can take advantage of those features, which is the majority justification for the ORM in the first place. You are basically suggesting what the original post author is suggesting. The comment above provided a rebuttal to their argument and you replied by suggesting the same thing they originally rebutted to. Hence a circular argument.
- jpc0 3y ago
  > But ORMs are about moving data around, transforming it from rows and columns into meaningful objects in the project's language and data model. I made my point about this but will repeat, I am generally writing validation for this, adding the code that converts this into known types isn't significantly more work, if I was never writing the validation this point would make sense. Also the ORM the parent comment is an author of doesn't do this, it generates a class with a ton of ancillary ORM specific functions that I don't care for and many ORMs do that. I don't even agree with what the article states, the article is effectively creating a custom ORM, I'm saying write a function that converts the data from your database driver to the type of thing you want, write a function that validates that data, those two can be 1 function for simple data but likely will be 1 function which is a composition of other functions. When you get to the point where that is tedious you now likely have a good idea of what you want in an ORM and are significantly better equipped to make an informed decision for your specific project, you might find you end up only wanting a query builder. Regarding abstraction over database drivers, well how often do you need an abstraction over database drivers, are you really using two or more different databases in a single project? My ideal workflow is: 1. Query exactly what I want 2. Make it valid data in the form I want That valid data shouldn't have a ton of extra stuff attached to it, I want plain old data that is validated and the correct type. Why would I add a dependency that is complex before I can make an informed decision that I would even need it?
  - deleted 3y ago
    [deleted]
  - aforwardslash 3y ago
    > Regarding abstraction over database drivers, well how often do you need an abstraction over database drivers, are you really using two or more different databases in a single project? Extending on this, you actually shouldn't even use different databases. There are bugs and quirks between different databases on things like string matching :) Having a multiple database project is often a nightmare, as you need to track all of these small differences and nuances that may affect the way your system works.
ris 3y ago
> Likewise practicing YAGNI This is why I have come to hate YAGNI. Nowadays when it's said what I hear is "I don't understand why I need it (yet)".
- jpc0 3y ago
  An app with 3 endpoints that makes 12 SQL queries won't need it. An app with 30 endpoints that makes 100s of queries might need it. In this case, it's a matter of not knowing whether you need it or even what iteration of it you need. Different ORMs have different tradeoffs, you don't even know which tradeoffs you want to make.

by jpc0 3y ago

jacurtis 3y ago

> I would argue to start with writing the basic SQL queries and adding an ORM later when you know you actually need it. I think you missed the point of the parent comment, which is that ORM's are not about writing SQL queries (although they do that). But ORMs are about moving data around, transforming it from rows and columns into meaningful objects in the project's language and data model. As the parent comment suggested, if you are dying to write your own SQL (which does often happen as queries get more complex and don't fit into ORM language model) then you can write raw SQL but still let the ORM do the heavy lifting so you can take advantage of those features, which is the majority justification for the ORM in the first place. You are basically suggesting what the original post author is suggesting. The comment above provided a rebuttal to their argument and you replied by suggesting the same thing they originally rebutted to. Hence a circular argument.

jpc0 3y ago
> But ORMs are about moving data around, transforming it from rows and columns into meaningful objects in the project's language and data model. I made my point about this but will repeat, I am generally writing validation for this, adding the code that converts this into known types isn't significantly more work, if I was never writing the validation this point would make sense. Also the ORM the parent comment is an author of doesn't do this, it generates a class with a ton of ancillary ORM specific functions that I don't care for and many ORMs do that. I don't even agree with what the article states, the article is effectively creating a custom ORM, I'm saying write a function that converts the data from your database driver to the type of thing you want, write a function that validates that data, those two can be 1 function for simple data but likely will be 1 function which is a composition of other functions. When you get to the point where that is tedious you now likely have a good idea of what you want in an ORM and are significantly better equipped to make an informed decision for your specific project, you might find you end up only wanting a query builder. Regarding abstraction over database drivers, well how often do you need an abstraction over database drivers, are you really using two or more different databases in a single project? My ideal workflow is: 1. Query exactly what I want 2. Make it valid data in the form I want That valid data shouldn't have a ton of extra stuff attached to it, I want plain old data that is validated and the correct type. Why would I add a dependency that is complex before I can make an informed decision that I would even need it?
- deleted 3y ago
  [deleted]
- aforwardslash 3y ago
  > Regarding abstraction over database drivers, well how often do you need an abstraction over database drivers, are you really using two or more different databases in a single project? Extending on this, you actually shouldn't even use different databases. There are bugs and quirks between different databases on things like string matching :) Having a multiple database project is often a nightmare, as you need to track all of these small differences and nuances that may affect the way your system works.

ris 3y ago

> Likewise practicing YAGNI This is why I have come to hate YAGNI. Nowadays when it's said what I hear is "I don't understand why I need it (yet)".

jpc0 3y ago
An app with 3 endpoints that makes 12 SQL queries won't need it. An app with 30 endpoints that makes 100s of queries might need it. In this case, it's a matter of not knowing whether you need it or even what iteration of it you need. Different ORMs have different tradeoffs, you don't even know which tradeoffs you want to make.