This is the kind of thing that I love to see as a blogpost, and I admire the ingenuity of the author, but I would hate to ever see this in a production codebase.
Unfortunately, most enterprise applications will have something like this, because they'll need to be customisable for individual companies. I've worked with a CA product years ago that had written their own SQL engine for doing exactly that. I would have much preferred the Django solution.
Totally in sync with you. I used to work for Zenefits, and if there's one technical reason I could point to for the company's failure to calculate accurate insurance rates (and eventually get a lot of support cases leading to lesser margins leading to an eventual failure in the insurance space), it was the blatant abuse of Django models.
Yeah anyone who did this in a codebase I manage would be on their way to looking for a new job. Trying to save a couple lines of code by relying on undocumented private API functions is seriously not acceptable, especially when there are multiple other ways of doing this.
This is not about "trying to save a couple lines of code" at all. Sometimes you want to gives the customer the ability to customize the app however they want and sometimes this is needed in order to do that. E.g. custom profile fields, building custom forms themselves (like Google Forms), etc.
shezi|7 years ago
paulie_a|7 years ago
plicense|7 years ago
Alex3917|7 years ago
Good blog post though.
Walkman|7 years ago