BertrandBordage
commented
7 years ago There is no fundamental problem with it. The real problem is that supporting a database backend means:
- Testing it
- Knowing it well enough to avoid doing something wrong, because all database implementations have specificities
- Maintaining this support for years
So this means additional initial work & maintenance work, for something that’s rarely used by djangonauts (and I’ve never used once).
In the case of ODBC, it’s even worse, because it’s not a database, but a database abstraction layer. To test it properly, it means we have to test ODBC with SQLite, MySQL & PostgreSQL. And it means installing ODBC layers on Travis CI for all these databases, which I’m not sure is possible.
That being said, if you’re willing to add pyodbc support and maintain it, you’re welcome to do it!
Of course, in the meantime you can use SILENCED_SYSTEM_CHECKS to use cachalot anyway, it should work fine, but I can’t give you a 100% guarantee.
cachalot clearly states on startup that pyodbc is not supported.
We're relying on a third party DB over a VPN connection, for which can only use pyodbc. The data is static and read-only, so cachalot would really be useful in this scenario. I'd be willing to spend some time figuring out what to do to make it supported, at least in our scenario. But in the comments of #15, you state that it will never be supported. Could you explain the reasoning behind that? Is there something fundamentally uncachable about pyodbc? Or are you just not interested in supporting pyodbc?