3 ms·
The problem is not the ORM. Anyone who is writing such complex queries directly in the controller needs to re-think how they have designed their site. Specifici
by teilo 16y ago
The problem is not the ORM. Anyone who is writing such complex queries directly in the controller needs to re-think how they have designed their site. Specificity like this belongs in the View and the DB itself, not in the Controller OR the Model.
Adding umpteen custom getters to the Model is not helping matters. It may be easier to test, but it is just as unwieldy and difficult to maintain. It is the wrong solution to the problem. These things need to be parametized in some way and made generic.
In Django you would likely do this with Q objects, and a front-end that lets you filter down your results on-the-fly, and save the resulting query to the DB for recall later. This is even easier to test, and prevents your Models from getting cluttered with functions which are far too specific.
- mononcqc 16y agoI didn't know about Q objects before. What are their capabilities regarding, say, moving from an SQL database to a web-service or a third party application? I mean, this is the kind of stuff I have to do surprisingly often when maintaining legacy applications and putting them up to date. Your data model ends up changing or just not supporting all the same idioms again. You might need to join some info coming from your database without half of it coming from a RPC. I've found such changes in the foundations of where data you get is to cause a whole damn lot of problems on all the layers above. I haven't figured out a better way than wrapping lots of it in fat models, but if Q objects have something that can help with that I'd be very happy to learn about it.
- teilo 16y agoQ objects are a way to represent complex SQL in a progressive fashion that would be unwieldy or impossible with the standard Django ORM chaining technique. It really doesn't address your use case.