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.
> 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.
What's wrong with using a JSONField with a different Cerberus validator for each client, and then using a Django form (and possibly some custom admin template code) to make it possible for the client to perform CRUD operations in the admin?
I personally would still just build a React front end and do the CRUD operations via REST endpoints, but if you really want to use the Django Admin then that's a much better way to do it than monkey patching the migrations system.
