Closed copelco closed 3 years ago
Hi Colin,
I'd be happy to review, merge and release such a PR, if it's coded well (mainly meaning following the style of the project, adding tests and documentation) and no breaking changes are introduced (everything should remain as is for current users with just the default database).
I think there's also issues about this in the original repo (https://github.com/mypebble/django-pgviews/issues/39, https://github.com/mypebble/django-pgviews/pull/52) and there's also an unfinished PR for this in this repo (https://github.com/mikicz/django-pgviews/pull/1), so it seems a lot of people could use this!
Implemented in https://github.com/mikicz/django-pgviews/pull/10, released as 0.8.0
to PyPI.
Projects using multiple databases cannot use
django-pgviews
outside of thedefault
database.I'm using
django-pgviews
on a project connected to two databases. In our case, thedefault
database is quite small, while the 2nd database is large and could make valuable use of materialized views.To support multiple databases, I think the following modifications need to be made:
Modify how connection cursors are obtained to make use of the connections dictionary:
https://github.com/mikicz/django-pgviews/blob/269c17f3e08c76a7cb971afcf2241ee76858589c/django_pgviews/view.py#L176
https://github.com/mikicz/django-pgviews/blob/269c17f3e08c76a7cb971afcf2241ee76858589c/django_pgviews/view.py#L441
Update view creation to refer to the database router's allow_migrate so views are only created within the appropriate database.
Update management commands to support running against specific databases, as migrate works. For example:
In the end, the majority of users using a single database shouldn't notice any differences and everything will continue to function as normal 🤞
I have a proof of concept currently working on a fork. Would there be any interest in possibly incorporating these changes if I can put together a PR?