I don't think this would be that helpful, Django relies on ducktyping, and the router docs ( https://docs.djangoproject.com/en/2.2/topics/db/multi-db/ ) clearly document the signatures, and that the methods are all optional:
A router doesn’t have to provide *all* these methods – it may omit one or > more of them. If one of the methods is omitted, Django will skip that > router when performing the relevant check. Additionally ABC's in Python don't place any restrictions on their subclasses. Even with an ABC it is possible to implement the wrong method names or signatures. For example: In [1]: import abc In [2]: class X(abc.ABC): ...: @abc.abstractmethod ...: def foo(self, number): ...: pass ...: In [3]: class Y(X): ...: def foo(self, number, number2): ...: return number * number2 ...: In [4]: Y().foo(2, 3) Out[4]: 6 As the Python docs state ( https://docs.python.org/3/glossary.html ), ABC's complement, and don't replace, duck-typing: > abstract base class > Abstract base classes complement duck-typing by providing a way to define > interfaces when other techniques like hasattr() would be clumsy or subtly > wrong (for example with magic methods). Thanks for the suggestion though. If you're interested in validating backends, I think a system check ( https://docs.djangoproject.com/en/2.2/ref/checks/ ) could be added to verify the provided routers have the correct signatures for the method names they implement. On Sun, 28 Apr 2019 at 09:20, Rick van Hattem (wolph) <wolp...@gmail.com> wrote: > Hi guys, > > It seems to me that an (abstract) base class for the database routers > would be useful to inherit for people. Makes implementing a router slightly > easier. > > I was thinking something along these lines: > import abc > > > class ConnectionRouterBase(abc.ABC): > > @abstractmethod > def db_for_read(self, model, **hints): > ... > > @abstractmethod > def db_for_write(self, model, **hints): > ... > > @abstractmethod > def allow_relation(self, obj1, obj2, **hints): > ... > > @abstractmethod > def allow_migrate(self, db, app_label, **hints): > ... > > Would a pull request like that be acceptable? > > ~rick > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c0e572d8-9075-4061-9c3b-e5074db2159e%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c0e572d8-9075-4061-9c3b-e5074db2159e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2hjQvNdf2pEnThvWZJrscc3Q2PH_u%3DH7i%3Dds0eKM8o3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
