Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#10096 closed (wontfix)

Added DBMS LINTER backend

Reported by: chernyshov Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Added backend for DBMS LINTER in list of backends.

New files:

  • django\db\backends\linter\init.py
  • django\db\backends\linter\base.py
  • django\db\backends\linter\client.py
  • django\db\backends\linter\creation.py
  • django\db\backends\linter\introspection.py
  • django\db\backends\linter\query.py

Changed files:

  • docs\faq\install.txt
  • docs\ref\databases.txt
  • docs\ref\settings.txt
  • docs\topics\install.txt

Attachments (1)

added linter backend.diff (26.9 KB) - added by chernyshov 7 years ago.
added LINTER backend for Django

Download all attachments as: .zip

Change History (4)

Changed 7 years ago by chernyshov

added LINTER backend for Django

comment:1 Changed 7 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

Nice work! :-)

However... our policy is not to add new database backends until they are well established with a history of continued support. Database backends can be used without requiring them to be included in core, (this is the fastest link I can find for the moment). It's a big problem if we include something and then the maintainer(s) lose interest, or aren't responsive or the quality just isn't there. Everybody looks bad, and the users become disappointed when something that looks like it's supported turns out not to be. We've had this problem in the past and are much more careful now.

So, the best idea is to create your backend as a standalone package and make it available via a service such as Google Code. That way there's a place for people to report bugs and everything. You won't need to patch any Django code to this; put the backend in its own module namespace and people can set the DATABASE_ENGINE setting appropriately.

If, at some point in the future, there's a lot of usage of this code and a history of support and bug fixes, you might wish to propose it for inclusion in core. But that is a last step, not a first one.

Closing as wontfix for the above reasons. It's not something to include in core at the moment. You might well want to make an announcement about it on django-users, though. There could well be people interested in trying this out.

comment:2 follow-up: Changed 6 years ago by anonymous

=(
linter is need russia security systems. No linter - no django=(

comment:3 in reply to: ↑ 2 Changed 6 years ago by ubernostrum

Replying to anonymous:

=(
linter is need russia security systems. No linter - no django=(

Please read Malcolm's explanation again: there is no need for this backend to be directly distributed as a part of the core Django framework, because Django can use any class implementing the proper API as a backend, regardless of whether that class is a part of Django or is a third-party module installed somewhere else.

Therefore, you can take the code above, put it into your own package, point your DATABASE_BACKEND setting at it, and do whatever you need with Django.

Note: See TracTickets for help on using tickets.
Back to Top