Creating internal/admin pages without Models

[Vasanth Mohan]

Hello,

I'd like to gauge the general opinion of more experienced devs before 
starting on a project.

I personally love the sheer flexibility that the django admin provides me 
to get started on the DB and manage the backend. I can add actions, filters 
and charts with just a few third-party apps. On top of that, permissions to 
control user access to everything.

However, I find myself having to build a separate set of templates and view 
for internal use often as the admin is tightly tied to the DB. I find 
myself not being able to expose the admin as it requires too much 
customisation to be useful to tech & non-tech teams at the same time. 
Moreover, DB structure is not as intuitive to non-tech users.

So I'd like to build a generic admin view that is not tied to the DB but 
can still leverage the widgets (tables, inputs, messages etc.) that Django 
offers. A set of tools to design custom pages like django-etc and design 
easy-to-customise top/sidebars

My question to the reader is quite simple, is this something feasible ? Are 
all widgets tightly coupled and expect models to function ? Anything you 
believe that might trip me up? 

Thanks,
Vaz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d6146414-c423-4f2a-b482-5eccb971f16cn%40googlegroups.com.

Re: Creating internal/admin pages without Models

[Vasanth Mohan]

Hi Igor,

Most of my cases are for internal tools and grouping together unrelated
tables as you just summarised. Some examples are,

- Writing text that can need to send out to clients by triggering a
predefined email templates
- Creating internal forms that should be saved to multiple tables or throw
an error
- Custom templates for showing unrelated & unrelated data

While these can be done normally with templates, the key difference is
these are internal pages and do not need to be super stylised. Performance
is far more important than the UI. A minimal stylisation would be good
enough is most cases.

Being able to leverage admin widgets would improve task turnaround time and
reduce frontend work to only client-facing logic.


Vasanth MOHAN


On Tue, 25 Oct 2022 at 14:10, Igor Margitich  wrote:

> Hi Vasanth,
>
> Can you ptovide an example when do you need generic admin view? I have
> case where I need gather some information from different not directly
> related tables. I have used
> https://pypi.org/project/django-nonrelated-inlines/. Can't say it is
> exactly what I need but seems it does the job.
> Also sometimes I need action's intermediate page which is more then just
> simple template. This is the case where would be nice to have CBV. Watch
> this presentation to get some ideas about CBV actions
> https://youtu.be/HJfPkbzcCJQ?t=1817.
>
> Best regards,
> Ihor
>
> вт, 25 окт. 2022 г. в 11:22, Vasanth Mohan :
>
>> Hello,
>>
>> I'd like to gauge the general opinion of more experienced devs before
>> starting on a project.
>>
>> I personally love the sheer flexibility that the django admin provides me
>> to get started on the DB and manage the backend. I can add actions, filters
>> and charts with just a few third-party apps. On top of that, permissions to
>> control user access to everything.
>>
>> However, I find myself having to build a separate set of templates and
>> view for internal use often as the admin is tightly tied to the DB. I find
>> myself not being able to expose the admin as it requires too much
>> customisation to be useful to tech & non-tech teams at the same time.
>> Moreover, DB structure is not as intuitive to non-tech users.
>>
>> So I'd like to build a generic admin view that is not tied to the DB but
>> can still leverage the widgets (tables, inputs, messages etc.) that Django
>> offers. A set of tools to design custom pages like django-etc and design
>> easy-to-customise top/sidebars
>>
>> My question to the reader is quite simple, is this something feasible ?
>> Are all widgets tightly coupled and expect models to function ? Anything
>> you believe that might trip me up?
>>
>> Thanks,
>> Vaz
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d6146414-c423-4f2a-b482-5eccb971f16cn%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/d6146414-c423-4f2a-b482-5eccb971f16cn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/yFJz4GPTJPo/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHi_fyv7QrWwpNOdyv8ZvOg%2B84mzTLKvrc-iYHjee8SQ6gPd%2Bg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAHi_fyv7QrWwpNOdyv8ZvOg%2B84mzTLKvrc-iYHjee8SQ6gPd%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOAVv_NQpKDOsEEYoGe13DyKWkb9Hm-VidrcLv%2BKrwbVQ30v1A%40mail.gmail.com.

Re: Creating internal/admin pages without Models

[Vasanth Mohan]

Hi Carlton,

While django-admin-views <https://github.com/frankwiles/django-admin-views>
indeed gives us the option to add custom views, it still is locked to the
App/Model based organisation which reflects the DB. Moreover, it still
necessitates that I build the page by hand.

I'm interested to know if it would be possible to reuse the admin widgets
like ListView Table with its filters, search etc on a custom view.

Thanks,
Vasanth MOHAN


On Tue, 25 Oct 2022 at 21:40, Carlton Gibson 
wrote:

> Check out Django-admin-views
>
> https://github.com/frankwiles/django-admin-views
>
> I think it needs a bit of an update for recent versions of Django (but I
> suspect those are minor) and o tho knit does what you’re after (or close)
>
> On Tuesday, 25 October 2022, Vasanth Mohan  wrote:
>
>> Hi Igor,
>>
>> Most of my cases are for internal tools and grouping together unrelated
>> tables as you just summarised. Some examples are,
>>
>> - Writing text that can need to send out to clients by triggering a
>> predefined email templates
>> - Creating internal forms that should be saved to multiple tables or
>> throw an error
>> - Custom templates for showing unrelated & unrelated data
>>
>> While these can be done normally with templates, the key difference is
>> these are internal pages and do not need to be super stylised. Performance
>> is far more important than the UI. A minimal stylisation would be good
>> enough is most cases.
>>
>> Being able to leverage admin widgets would improve task turnaround time
>> and reduce frontend work to only client-facing logic.
>>
>>
>> Vasanth MOHAN
>>
>>
>> On Tue, 25 Oct 2022 at 14:10, Igor Margitich  wrote:
>>
>>> Hi Vasanth,
>>>
>>> Can you ptovide an example when do you need generic admin view? I have
>>> case where I need gather some information from different not directly
>>> related tables. I have used
>>> https://pypi.org/project/django-nonrelated-inlines/. Can't say it is
>>> exactly what I need but seems it does the job.
>>> Also sometimes I need action's intermediate page which is more then just
>>> simple template. This is the case where would be nice to have CBV. Watch
>>> this presentation to get some ideas about CBV actions
>>> https://youtu.be/HJfPkbzcCJQ?t=1817.
>>>
>>> Best regards,
>>> Ihor
>>>
>>> вт, 25 окт. 2022 г. в 11:22, Vasanth Mohan :
>>>
>>>> Hello,
>>>>
>>>> I'd like to gauge the general opinion of more experienced devs before
>>>> starting on a project.
>>>>
>>>> I personally love the sheer flexibility that the django admin provides
>>>> me to get started on the DB and manage the backend. I can add actions,
>>>> filters and charts with just a few third-party apps. On top of that,
>>>> permissions to control user access to everything.
>>>>
>>>> However, I find myself having to build a separate set of templates and
>>>> view for internal use often as the admin is tightly tied to the DB. I find
>>>> myself not being able to expose the admin as it requires too much
>>>> customisation to be useful to tech & non-tech teams at the same time.
>>>> Moreover, DB structure is not as intuitive to non-tech users.
>>>>
>>>> So I'd like to build a generic admin view that is not tied to the DB
>>>> but can still leverage the widgets (tables, inputs, messages etc.) that
>>>> Django offers. A set of tools to design custom pages like django-etc and
>>>> design easy-to-customise top/sidebars
>>>>
>>>> My question to the reader is quite simple, is this something feasible ?
>>>> Are all widgets tightly coupled and expect models to function ? Anything
>>>> you believe that might trip me up?
>>>>
>>>> Thanks,
>>>> Vaz
>>>>
>>>> --
>>>> 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 view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/d6146414-c423-4f2a-b482-5eccb971f16cn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/d6146414-c423-4f2a-b482-5eccb971f16cn%40g

Switch to a dropdown widget for ListFilter on admin

[Vasanth Mohan]

Hello,

When there are multiple filters on a model, the filter sidebar gets 
cluttered quite rapidly. Is there a specfic reason, we list the options 
over a dropdown? 

I'd like to see if there is support to change the default filter widget to 
dropdown? I'd like to reiterate, this merely replaces the list with a 
dropdown, this should not change anything at a functional level. Anything 
complex can continue to use third-party apps.

Thanks
Vasanth

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a16ee31b-1f82-47c3-917c-56b8d3b7f892n%40googlegroups.com.

Re: Switch to a dropdown widget for ListFilter on admin

[Vasanth Mohan]

Hi David,

While I understand the ease of use that ListFilter bring in, my issues are

1. If there are multiple filters with multiple options, the user cannot at
a glance see all the filters active / available without scrolling
2.  when using multiple filters, the page is refreshed on each filter option

Potential solution;
To fix only 1 : When using the dropdown, the widget used is the same
as *Charfield+options.
*This is still a consistent design as ListFilters is built on a list of
options*.* Moreover, since it is a standard form element, standard
accessibility attributes can be used. Visually, the page can just show the
filters available which is the immediate concern when looking at filters.

To fix both, (which is out of scope unless someone is interested), we can
treat list filters as a part of "Search Form" with an apply button. This
will allow users to select multiple filters and apply the filters with a
single request.

Cordialement,
Vasanth MOHAN


On Fri, 4 Nov 2022 at 06:03, David Sanders 
wrote:

> Hi Vasanth,
>
> What advantages does a dropdown have over simply placing the options there
> though? Typically these sorts of things have horrendous accessibility and
> make the code more complex.
>
> --
> David
>
> On Fri, 4 Nov 2022 at 02:17, Vasanth Mohan  wrote:
>
>> Hello,
>>
>> When there are multiple filters on a model, the filter sidebar gets
>> cluttered quite rapidly. Is there a specfic reason, we list the options
>> over a dropdown?
>>
>> I'd like to see if there is support to change the default filter widget
>> to dropdown? I'd like to reiterate, this merely replaces the list with a
>> dropdown, this should not change anything at a functional level. Anything
>> complex can continue to use third-party apps.
>>
>> Thanks
>> Vasanth
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a16ee31b-1f82-47c3-917c-56b8d3b7f892n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/a16ee31b-1f82-47c3-917c-56b8d3b7f892n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/b_nzFu4gg7I/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-7QTcHfsp0822DbvwpudGPxjY_ehKGvjxKifJ4_KdNUCg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-7QTcHfsp0822DbvwpudGPxjY_ehKGvjxKifJ4_KdNUCg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOAVv_P6FGYvKALtJ2FcobZ3seDmQ07Pi-Cz1fsnSYaEuV3ziA%40mail.gmail.com.

Re: Standalon Django ORM

[Vasanth Mohan]

I second Jörg about better maintainability with tighter integrations.

However, for the fun of stirring the pot, what's the opinion on letting 
Django define an API for the ORM and letting a library deal with the 
DB-specific implementation that generates the SQL for query?  Django could 
have a list of officially supported DBs ('django.db.postgres') to be 
included in the INSTALLED_APPS to select the DB to be used.

Meanwhile, the community can come up with support for other DBs like 
CockroachDB, Mongo etc. (just an idea borrowed off the rust community). It 
can even allow adding additional filters/commands specific to the DB.

Vaz

On Monday, 12 December 2022 at 13:07:50 UTC+1 j.bre...@netzkolchose.de 
wrote:

> I tend to believe the opposite is true. Django was/is a successor in its 
> field, because it offers an "out-of-the-box" or "batteries included" 
> experience. Subsequently parts were shaped as needed for that bigger 
> picture, e.g. the ORM became what it is today.
>
> Does anyone still remember django versions with external south 
> migrations? Was much more tricky to get done right, ppl would just 
> forget it, do it in wrong order, whatsoever. Got basically fixed by the 
> tighter integration with typical django project lifecycling.
>
> By making the ORM an external lib with its own progression and 
> versioning you'd reintroduce all that fuzz again, plus frictions from 
> API changes, that seem logical from a db maintainer viewpoint, but make 
> life harder at consumer end (would be django here). By keeping it in one 
> place those tiny viewpoint differences can be leveled out upfront.
>
> Ofc mammoths move slower, but they are also more resilient against 
> disturbance. In terms of good long term maintainability the more 
> granular/agile approach as seen in the JS-world still has to prove 
> itself. Projects there need a lot more care&love of their dependency 
> lists, and typically wont run anymore after 1-2 years without manually 
> fixing this or that, because package xy of 100+ dependencies turned its 
> API upside-down for no good reason.
>
> So no, outsourcing things is not always a good idea.
> All imho, ofc.
>
> Cheers,
> Jörg
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d405433e-3ce4-4737-9539-47012a405b9en%40googlegroups.com.

Custom Ordering and Grouping of Models in Django Admin

[Vasanth Mohan]

As the numbers Models in an app grows, it becomes tedious to find the model 
we are searching for in a long list on the index page (and navigation bar) 
of the Django admin

As a part of a new project, I wanted to reorder and logically group models 
that do not necessarily reflect the apps of the project. I found this 
little library called 
[django-modeladmin-reorder](https://github.com/mishbahr/django-modeladmin-reorder)
 
that does it by remapping the fields with a middleware.

However, I think it would be cleaner if Django supported it natively as 
this can be useful in almost every project. A layer called AdminApp between 
the `admin` and the ModelAdmin registered would be the perfect middle 
ground.

**Proposal**

- Create a new class in admin called `AdminApp` 
- The AdminApp should be registerable to admin
- The AdminApp should accept ModelAdmin to be registered with it 
- Wire up the ModelAdmins and AdminApps to see custom layout that is not 
tied to apps
- For all ModelAdmins registered directly to admin, fallback to current 
implementation

```
class AgencyAdmin(admin.ModelAdmin):
   pass

class AgencyConfigAdmin(admin.ModelAdmin):
   pass

class AgencyAdminApp(admin.AdminApp):
   label = "Agency Details"

class AgentAdmin(admin.ModelAdmin):
   pass


admin.register(AgentAdmin) # Existing implementation

# Option 1 : without decorators
## Add Models to AdminApp
AgencyAdminApp.register(AgencyAdmin)
AgencyAdminApp.register(AgencyConfigAdmin)
## Add New AdminApp tp Admin
admin.register_app(AgencyAdminApp) 

# Option 2 : with decorators
admin.register(AgencyAdmin, admin_app=AgencyAdminApp)
admin.register(AgencyConfigAdmin, admin_app=AgencyAdminApp)
```

I feel like this seems like a decent middle ground that doesn't break 
existing implementation but allows the app to be expanded in the future. 

So what do you think about the idea? If the core team is interested, I'll 
be more than willing to work on this but I am first time contributor and 
will need some mentoring on it.

 I've also made a forum post for the same : 
https://forum.djangoproject.com/t/custom-admin-apps-for-grouping-and-reordering-models/9723

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dd42ef6b-a52b-4ab0-b579-1114eb92b0f4n%40googlegroups.com.

Autocomplete Foreign Keys by default in Admin

[Vasanth Mohan]

The admin page for any object becomes ridiculously slow (upto 10s) when the 
object and its multiple inlines have foreign keys. The latency just 
disappears after i added autocomplete for each one manually.

Is there any reason why foreign keys are not autocomplete by default ? Will 
the devs be interested in changing the default behaviour for foreign key in 
admin ? Or accepting a patch for the same?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eafcd382-ba33-48b3-bb8a-7bad12f623a4n%40googlegroups.com.

Re: Developing an SPA version of Django admin

[Vasanth Mohan]

Hi Warren,

An SPA sound interesting but should be based on React or other SPA 
frameworks? While I’ve not looked into it very much Webcomponents are part 
of the Spec since 2012. Vanilla JS can be leveraged to create the admin and 
the project developers can choose to extend it with the framework of their 
choice.

I’m relatively a inexperienced  developer but I’d very interested in 
contributing with a project like this.

On Friday, 15 October 2021 at 18:54:26 UTC+2 warren@gmail.com wrote:

> Hi everyone,
>
> I've been contemplating the development of an SPA version of admin either 
> in Angular, React, Vue or even Flutter... preferably in Angular due to it's 
> data binding approach.
>
> The idea is to serve the SPA from Django, dynamically generating it so 
> that the great model based apps that one can create with the current admin 
> site can be dynamically generated in a similar way, but as an SPA.  Why 
> SPA.. just to enable a better, more powerful user experience without the 
> round trips and page reloads.   
>
> Hoping it will in the same way form a RAD tool for SPA development with a 
> Django back-end.
>
> If we get really smart, we may be able to make it theme-able.
>
> I have messaged the django dev group as I have had a look at the work that 
> may be involved and I believe that if we we're to succeed in making this a 
> standard addition to django as an admin alternative, we make have to 
> accommodate it in the code a bit... there may be a bit of refactoring of 
> the admin code. 
>
> Just wondering if anyone would be up for joining me in creating something 
> like this?... or if you know of an existing project trying to do this?
>
> Thanks
> Warren
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cb6cc6fc-b1d1-4a9c-879e-2c9325af026cn%40googlegroups.com.

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( ... )
   

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

Re: Adding Support for DB Views

[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.


On Tuesday, 22 February 2022 at 10:18:05 UTC+1 al...@interia.eu wrote:

> 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.
>
>
>
> 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.
>
>  
>
> *From:* django-d...@googlegroups.com  *On 
> Behalf Of *Vasanth Mohan
> *Sent:* Monday, February 21, 2022 8:21 AM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Adding Support for DB Views
>
>  
>
> 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 
> <https://us-east-2.protection.sophos.com?d=knexjs.org&u=aHR0cHM6Ly9rbmV4anMub3JnLyNTY2hlbWEtY3JlYXRlVmlldw==&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=VlZ3M2llM3EwdHFtZG03WnZMTFBmdDkxUG1nNFNOUEFwYSt2ZUoyY2dmOD0=&h=b1dc1a4a21604d3ea180a144eae9d276>
>  
> 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( ... )
>
>
>
>  
>
> -- 
> 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
>  
> <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL2UwMDljMWJkLThhNjgtNDg2YS04YjdmLTdjM2Q5ZTM1NTNlZW4lNDBnb29nbGVncm91cHMuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=RGFkbkVWSFB3MS90WENZby83RnZTSTltUGVNK2hNYkxuWXZhZXc1WXlZTT0=&h=b1dc1a4a21604d3ea180a144eae9d276>
> .
>
> -- 
> 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/b5f0b99b068a4ea192797708d4f5037d%40Exchange.ISS.LOCAL
>  
> <https://groups.google.com/d/msgid/django-developers/b5f0b99b068a4ea192797708d4f5037d%40Exchange.ISS.LOCAL?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/329945c3-8981-4f9f-935e-830516181d2cn%40googlegroups.com.