Adding Support for DB Views

[Vasanth Mohan]

Are there any plans to support DB Views ? Would the team be interested in mainlining it if there is a PR for it ?

I tend to use DB Views on Postgres at my day job and wouldn't mind adding basic support across Django's supported DBs. I'll probably take inspiration from Knex.js to implement it.

I'm imagining something along the lines of,

class NewView(models.ViewModel):

         def view_qs(self):
                return qs # Define with QS  to be used in CREATE VIEW App_ViewModel as QS;

migrations.CreateViewModel( ... )

migrations.DeleteViewModel( ... )

migrations.UpdateViewModel( ... )

  

[Matthew Pava]

Currently, I just use the migrations to do a RunSQL and then I make a model with the Meta option managed set appropriately. It works for me, but perhaps something a bit more convenient is in order these days.

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e009c1bd-8a68-486a-8b7f-7c3d9e3553een%40googlegroups.com.

[Albert]

Hi,

I am using the same approach, migrations with RunSQL and model and in most cases it is working well.

Introduction of supporting views is easy at a first glance. But when you think more then it is not so easy. People would see the view in admin panel, but admin panel is based on an idea that every model has primary key but view hasn't got one.

So it would be required to disable adding and editing of data - only reading for that model. But some databases allow to insert data through a view so it became an issue how to support that.

It also involves support of queryset, migrations, reverse engineering (inspectdb), generic views and some other details of the views in different database engines.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b5f0b99b068a4ea192797708d4f5037d%40Exchange.ISS.LOCAL.

[Vasanth Mohan]

I was thinking of support for just the DDL commands, with read-only data access.

IMHO, There are actually two major caveats with trying to go for fully managed support for Views

1. Insert, update and delete varies between DBs and SQLite doesn't support it at all

2. Materialized Views

For (1), I was hoping the ViewModel base class can use an abstract class with a NotImplemented error for the C*UD logic and allow just read-only permission by default. The dev can choose to enable the permissions for insert/update. This is imperative as you've pointed out, the design of the View is very subjective and will vary from project to project and even within projects. So it's best left to the developer to define the data manipulation that best suits their use case.

Regarding (2), I was considering it to be out of scope for this proposal as that introduces too much complexity with just one task.