Re: Support for No-SQL database in Django

[Jacob Rief]

Hello Vineet,
you can perfectly use MongoDB together with Django. In fact I do that in 
one of my projects and where I use it, it perfectly makes sense.

The question you raised is, if the Django community can adopt the ORM for 
non-relational databases, such as MongoDB. I would say
no, for the same reasons as explained by Aymeric.

Now ask yourself why you want that.
Do you need aggregations, database functions, joins with filtering on 
foreign keys, etc.? Then you should consider a relational database anyway.
Or would you just like to define models and have the Django admin generate 
some nice editors for your non relational data-model?
If the latter is the case, then that's a valid point! In fact, maybe the 
Django admin should provide hooks for extension, in order to add list- and
detail-views, not handled by the Django-ORM-to-Django-Admin mapper.

Just my two cents ...

– Jacob

-- 
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/9166748c-8e2f-45d2-9ffd-14002e1116fen%40googlegroups.com.

Re: Improving MSSQL and Azure SQL support on Django

[Warren Chu]

@Florian, @Adam - Thanks for the feedback. Focusing on MSSQL as a 3rd party 
backend sounds good, indeed even as the long-term goal. We have no 
directive at this point that inclusion into Django core is mandatory, so I 
think we're aligned in terms of practical goals. I'm sure we'll have new 
perspectives and opinions in 1 year's time, and we can re-evaluate or 
confirm this current sentiment at that time. Thanks again.

Cheers,
Warren

On Friday, 4 December 2020 at 00:27:29 UTC-8 Adam Johnson wrote:

> Please keep in mind that Phase 2 is something that might never happen. We 
>> have a tendency to not bloat Django and there is no reason why a database 
>> backend cannot live outside of core.
>>
>  
> I agree here with Florian. It's not *impossible* to consider merging the 
> backend, but I think we'd want to see several years of ongoing support from 
> MS before even considering it.
>
> Keeping it outside of core can probably work in your favour, with the 
> ability to update support for new features or versions of SQL Server 
> outside of Django's release cadence.
>
> On Fri, 4 Dec 2020 at 07:39, Florian Apolloner  wrote:
>
>> Hi Warren,
>>
>> > A) django-mssql is viewed as the Phase 1 focus and current preferred 
>> option with a longer term Phase 2 goal of including MSSQL as a supported 
>> backend for Django core
>>
>> Please keep in mind that Phase 2 is something that might never happen. We 
>> have a tendency to not bloat Django and there is no reason why a database 
>> backend cannot live outside of core. Tim Graham is currently working on a 
>> cockroach backend and is running against the builtin Django testsuite (+ 
>> submitting patches to Django where we need to alter tests due to reliance 
>> on PKs etc…). This approach works imo very well (I did the same when 
>> writing a backend for Informix). We are very supportive of 3rd party db 
>> backends in the sense that we usually quickly address issues in our 
>> testsuite etc to make testing those external backends against Django 
>> easier. In that sense there is no strong reason to include the MSSQL 
>> backend in core. Package management in Python works well enough to allow 
>> the backend to stay external. 
>>
>> Personally I think having the django-mssql backend with MS support behind 
>> it (be that test infra for the existing django-mssql fork etc) is already 
>> the icing on the cake.
>>
>> Cheers,
>> Florian
>>
>>
>> On Friday, December 4, 2020 at 2:59:43 AM UTC+1 vwa...@gmail.com wrote:
>>
>>> Thanks for the responses.
>>>
>>> @Florian - I've now reached out to the maintainers of ESSolutions as 
>>> well as the relevant previous Microsoft engagement owners, thanks for the 
>>> suggestion
>>>
>>> @Chris - This is excellent news indeed, we are excited to make progress 
>>> beginning with some small steps
>>>
>>> @r...@whidbey.com - 
>>> A) django-mssql is viewed as the Phase 1 focus and current preferred 
>>> option with a longer term Phase 2 goal of including MSSQL as a supported 
>>> backend for Django core
>>> B) I've now logged both your pain points as issues in our private repo 
>>> (which will be made public after internal compliance reviews)
>>> C) Happy to hear about your scaled production app using Django and 
>>> MSSQL. Could I ask you to send a "Hello" email to myself at 
>>> v-wa...@microsoft.com, so that we can follow up with eventual testing?
>>>
>>> @dans...@gmail.com - Your security concerns are important and noted, 
>>> I've flagged this for investigation as a priority
>>>
>>> Cheers,
>>> Warren
>>> On Friday, 27 November 2020 at 10:57:09 UTC-8 dans...@gmail.com wrote:
>>>
 I'd suggest someone talk with professional DBAs for MSSQL.  In my work, 
 which is Federal government, the DBA told me that disconnecting from PSQL 
 as "appuser" and attempting to connect to database "postgres" in order to 
 create the test database violated FISMA.  I had to subclass my own 
 postgresql backend to create the test user while connected to my actual 
 database.  I would imagine that the original reasons for doing it this way 
 harkens back to a time when people used the same database server for 
 production, staging, qa, and integration, and some of these environments 
 may not have existed. While in some organizations we have only production, 
 staging/qa, and development/integration, I would guess there are few cases 
 where the same database server is used for production and the other 
 environments.

 On Fri, Nov 27, 2020 at 1:18 PM r...@whidbey.com  
 wrote:

> Good news.  I've been using Django on MSSQL for about 8 years.  Couple 
> of things:
> - I've been using pyodbc, not django-mssql.  I note your messages from 
> 2015 include it as a library to check for compatibility; what was the 
> outcome of that?  Is it proposed that django-mssql become the 
> "best-practices" interface for SQL Server?
> - Couple of persistent pain points:
>  

Re: Trigger an event after running collapse.js

[Adam Johnson]

Rather than requiring changes to Django, I believe you can do this with a
MutationObserver to detect the class attribute changing on the
corresponding elements:
https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver/observe .
This has the advantage that we don't need to add custom events for every
single change that Django's JavaScript makes.

On Fri, 4 Dec 2020 at 14:57, Fab  wrote:

> When the admin's collapse script has finished it would be good to get an
> event I can listen to:
>
> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/collapse.js
>
> This would be useful for custom scripts that rely on the collapse class
> and elements being in place. It would be better than having to wait a few
> frames after the 'load' event to ensure the script has run already.
>
> Cheers,
>
> Fab
>
> --
> 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/170840dc-dfdd-40c7-bb69-a3e3f702d6f2n%40googlegroups.com
> 
> .
>


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

Trigger an event after running collapse.js

[Fab]

When the admin's collapse script has finished it would be good to get an 
event I can listen to:
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/collapse.js

This would be useful for custom scripts that rely on the collapse class and 
elements being in place. It would be better than having to wait a few 
frames after the 'load' event to ensure the script has run already.

Cheers,

Fab

-- 
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/170840dc-dfdd-40c7-bb69-a3e3f702d6f2n%40googlegroups.com.

Re: Integrated python shell in browser

[Adam Johnson]

Hi Manav

This is the kind of thing that we'd want to see in a third party package
before even considering it for core django

An existing implementation of a Python shell in the browser for Django
exists in the runserver_plus command of django-extensions:
https://django-extensions.readthedocs.io/en/latest/runserver_plus.html .
This is actually pulling the shell feature from a separate project,
werkzeug. This is intended for local debugging though and should NOT be
used in any kind of production environment.

3. the shell instance would be user-specific as per the permissions of the
> respective user.


How do you propose to implement this? If you give someone the full power of
Python, they can subvert any code you put in place to enforce permissions
(or read only, etc.). They could run python code that deletes all the files
on the server, or starts a bitcoin miner. This is such a high security risk
that I don't think we could put it in Django.

On Fri, 4 Dec 2020 at 14:01, Manav Agarwal  wrote:

> Hey everyone,
> I am Manav and I am contributing to Django for the last few months. I am
> developing projects using Django for the last 2 years. Currently, I was
> working on a Django based project and was facing a problem. Sometimes, I
> had to use the python manage.py shell along with the server running in the
> other terminal window. It was a hard job for me to maintain 2 shells
> running simultaneously though the other one which had the server running
> was nothing to do with but still it was open in the background and also had
> to manage browsers with them. Is there any functionality in Django to solve
> the problem?
> If there is not any, I may raise a ticket for this on trac and would be
> happy to work on it.
>
> Benefits of the feature would be as follows :
> 1. Admin would be able to work on a shell and database directly using a
> command-line interface integrated within the browser like the SQL shell we
> have in phpmyadmin.
> 2. No need to open a separate terminal for database management and shell.
> 3. the shell instance would be user-specific as per the permissions of the
> respective user.
> 4. A complete command-line interface to manage admin.
> 5. No need to move the mouse, again and again, to add entries to the data
> fields from the browser.
>
> --
> 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/3a828653-afb8-42fa-9912-fde32f5f7f09n%40googlegroups.com
> 
> .
>


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

Integrated python shell in browser

[Manav Agarwal]

Hey everyone,
I am Manav and I am contributing to Django for the last few months. I am 
developing projects using Django for the last 2 years. Currently, I was 
working on a Django based project and was facing a problem. Sometimes, I 
had to use the python manage.py shell along with the server running in the 
other terminal window. It was a hard job for me to maintain 2 shells 
running simultaneously though the other one which had the server running 
was nothing to do with but still it was open in the background and also had 
to manage browsers with them. Is there any functionality in Django to solve 
the problem? 
If there is not any, I may raise a ticket for this on trac and would be 
happy to work on it.

Benefits of the feature would be as follows :
1. Admin would be able to work on a shell and database directly using a 
command-line interface integrated within the browser like the SQL shell we 
have in phpmyadmin.
2. No need to open a separate terminal for database management and shell.
3. the shell instance would be user-specific as per the permissions of the 
respective user.
4. A complete command-line interface to manage admin.
5. No need to move the mouse, again and again, to add entries to the data 
fields from the browser.

-- 
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/3a828653-afb8-42fa-9912-fde32f5f7f09n%40googlegroups.com.

Re: Quick Filter in the Admin Sidebar

[Maxim Milovanov]

Hey guys,

I've updated my prototype. What's changed:
-- moved the JS and CSS to nav_sidebar.js and nav_sidebar.css respectively
-- slight changes in styling
-- added ESC key support

I've updated my gist 
https://gist.github.com/MilovanovM/84ffbbec02391c1ba1771a3a6aee5797
My changes are:
nav_sidebar.html: line 4
nav_sidebar.css: line 121 and below
nav_sidebar.js: line 40 and below

Here is the commit in my repo 
https://github.com/MilovanovM/django/commit/837701e79c468f72cbce1921b42c130801927e1c
I've attached a git patch file as well.

Thanks,
Maxim

пятница, 4 декабря 2020 г. в 12:00:35 UTC+3, Adam Johnson: 

> I'm not sure that the nav_sidebar.html is the best place for the JS 
>> snippet. Probably, it should be placed in the main JS. When DOM is ready it 
>> can be initialized there.
>
>
> Indeed, we can't use inline JS in the admin since that doesn't work with a 
> strict CSP. 
>
> On Fri, 4 Dec 2020 at 08:42, Maxim Milovanov  wrote:
>
>> Hey guys,
>>
>> I'm not sure that the nav_sidebar.html is the best place for the JS 
>> snippet. Probably, it should be placed in the main JS. When DOM is ready it 
>> can be initialized there.
>>
>> About UX. Agree the the "Clear" feature would be useful. It can be an "x" 
>> icon, or a shortkey (ESC?), or both.
>>
>> I'll provide a working sample later.
>>
>> Thanks,
>> Maxim 
>>
>> среда, 2 декабря 2020 г. в 20:46:30 UTC+3, Collin Anderson: 
>>
>>> I think this would be really helpful. Looking at the code in the gist, 
>>> that looks about right. It's not too complicated and the basic 
>>> toLowerCase()/indexOf() method of search should hopefully be enough (it's 
>>> what I would do if I were implementing this!). I'd suggest adding some sort 
>>> of clear or x button for canceling/removing the filter, but otherwise I 
>>> think this should be ok UX wise. We can always improve it later.
>>>
>>> On Thursday, November 19, 2020 at 9:38:25 AM UTC-5 t...@carrick.eu 
>>> wrote:
>>>
 I haven't looked at the gist, but I think in principle it's a good 
 idea. ctrl+f isn't ideal.

 I think we need to be careful that the UX is good, if we go with this.

 Tom

 On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov  
 wrote:

> Yeah, that's why I came up with that idea. There are two projects, 44 
> models on one, 57 models on another. It's very hard to navigate
>
> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com: 
>
>> I found this feature very helpful. I'm maintaining two sites with 
>> more than 20 models registered in the admin and some time is annoying 
>> when 
>> I try to find the one I'm looking for
>>
>> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim 
>> Milovanov escribió:
>>
>>> Hey guys,
>>>
>>> I've posted a ticket  with 
>>> a proposal to add a quick filtering feature to the sidebar.
>>> To see it in action just replace the content of nav_sidebar.html by 
>>> this 
>>> gist 
>>> 
>>>
>>> Does it worth adding to the admin features? Hope for any feedback.
>>>
>>> Thanks,
>>> Maxim
>>>
>> -- 
> 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/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com
>  
> 
> .
>
 -- 
>> 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/577ba446-7e78-42d8-8a1d-88db169475d4n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fefe1de6-874c-44d0-a2a6-2574ce257373n%40googlegroups.com.
>From 837701e79c468f72cbce1921b42c130801927e1c Mon Sep 17 00:00:00 

Re: Quick Filter in the Admin Sidebar

[Adam Johnson]

>
> I'm not sure that the nav_sidebar.html is the best place for the JS
> snippet. Probably, it should be placed in the main JS. When DOM is ready it
> can be initialized there.


Indeed, we can't use inline JS in the admin since that doesn't work with a
strict CSP.

On Fri, 4 Dec 2020 at 08:42, Maxim Milovanov  wrote:

> Hey guys,
>
> I'm not sure that the nav_sidebar.html is the best place for the JS
> snippet. Probably, it should be placed in the main JS. When DOM is ready it
> can be initialized there.
>
> About UX. Agree the the "Clear" feature would be useful. It can be an "x"
> icon, or a shortkey (ESC?), or both.
>
> I'll provide a working sample later.
>
> Thanks,
> Maxim
>
> среда, 2 декабря 2020 г. в 20:46:30 UTC+3, Collin Anderson:
>
>> I think this would be really helpful. Looking at the code in the gist,
>> that looks about right. It's not too complicated and the basic
>> toLowerCase()/indexOf() method of search should hopefully be enough (it's
>> what I would do if I were implementing this!). I'd suggest adding some sort
>> of clear or x button for canceling/removing the filter, but otherwise I
>> think this should be ok UX wise. We can always improve it later.
>>
>> On Thursday, November 19, 2020 at 9:38:25 AM UTC-5 t...@carrick.eu wrote:
>>
>>> I haven't looked at the gist, but I think in principle it's a good idea.
>>> ctrl+f isn't ideal.
>>>
>>> I think we need to be careful that the UX is good, if we go with this.
>>>
>>> Tom
>>>
>>> On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov 
>>> wrote:
>>>
 Yeah, that's why I came up with that idea. There are two projects, 44
 models on one, 57 models on another. It's very hard to navigate

 четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com:

> I found this feature very helpful. I'm maintaining two sites with more
> than 20 models registered in the admin and some time is annoying when I 
> try
> to find the one I'm looking for
>
> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim
> Milovanov escribió:
>
>> Hey guys,
>>
>> I've posted a ticket  with
>> a proposal to add a quick filtering feature to the sidebar.
>> To see it in action just replace the content of nav_sidebar.html by this
>> gist
>> 
>>
>> Does it worth adding to the admin features? Hope for any feedback.
>>
>> Thanks,
>> Maxim
>>
> --
 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/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com
 
 .

>>> --
> 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/577ba446-7e78-42d8-8a1d-88db169475d4n%40googlegroups.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0d4%3DaBJVkjP4iJ8PQp-%2BNxOzjNcn-4xHGXZaodhYK3xQ%40mail.gmail.com.

Re: Quick Filter in the Admin Sidebar

[Maxim Milovanov]

Hey guys,

I'm not sure that the nav_sidebar.html is the best place for the JS 
snippet. Probably, it should be placed in the main JS. When DOM is ready it 
can be initialized there.

About UX. Agree the the "Clear" feature would be useful. It can be an "x" 
icon, or a shortkey (ESC?), or both.

I'll provide a working sample later.

Thanks,
Maxim 

среда, 2 декабря 2020 г. в 20:46:30 UTC+3, Collin Anderson: 

> I think this would be really helpful. Looking at the code in the gist, 
> that looks about right. It's not too complicated and the basic 
> toLowerCase()/indexOf() method of search should hopefully be enough (it's 
> what I would do if I were implementing this!). I'd suggest adding some sort 
> of clear or x button for canceling/removing the filter, but otherwise I 
> think this should be ok UX wise. We can always improve it later.
>
> On Thursday, November 19, 2020 at 9:38:25 AM UTC-5 t...@carrick.eu wrote:
>
>> I haven't looked at the gist, but I think in principle it's a good idea. 
>> ctrl+f isn't ideal.
>>
>> I think we need to be careful that the UX is good, if we go with this.
>>
>> Tom
>>
>> On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov  
>> wrote:
>>
>>> Yeah, that's why I came up with that idea. There are two projects, 44 
>>> models on one, 57 models on another. It's very hard to navigate
>>>
>>> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com: 
>>>
 I found this feature very helpful. I'm maintaining two sites with more 
 than 20 models registered in the admin and some time is annoying when I 
 try 
 to find the one I'm looking for

 El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim 
 Milovanov escribió:

> Hey guys,
>
> I've posted a ticket  with 
> a proposal to add a quick filtering feature to the sidebar.
> To see it in action just replace the content of nav_sidebar.html by this 
> gist 
> 
>
> Does it worth adding to the admin features? Hope for any feedback.
>
> Thanks,
> Maxim
>
 -- 
>>> 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/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/577ba446-7e78-42d8-8a1d-88db169475d4n%40googlegroups.com.

Re: Improving MSSQL and Azure SQL support on Django

[Adam Johnson]

>
> Please keep in mind that Phase 2 is something that might never happen. We
> have a tendency to not bloat Django and there is no reason why a database
> backend cannot live outside of core.
>

I agree here with Florian. It's not *impossible* to consider merging the
backend, but I think we'd want to see several years of ongoing support from
MS before even considering it.

Keeping it outside of core can probably work in your favour, with the
ability to update support for new features or versions of SQL Server
outside of Django's release cadence.

On Fri, 4 Dec 2020 at 07:39, Florian Apolloner 
wrote:

> Hi Warren,
>
> > A) django-mssql is viewed as the Phase 1 focus and current preferred
> option with a longer term Phase 2 goal of including MSSQL as a supported
> backend for Django core
>
> Please keep in mind that Phase 2 is something that might never happen. We
> have a tendency to not bloat Django and there is no reason why a database
> backend cannot live outside of core. Tim Graham is currently working on a
> cockroach backend and is running against the builtin Django testsuite (+
> submitting patches to Django where we need to alter tests due to reliance
> on PKs etc…). This approach works imo very well (I did the same when
> writing a backend for Informix). We are very supportive of 3rd party db
> backends in the sense that we usually quickly address issues in our
> testsuite etc to make testing those external backends against Django
> easier. In that sense there is no strong reason to include the MSSQL
> backend in core. Package management in Python works well enough to allow
> the backend to stay external.
>
> Personally I think having the django-mssql backend with MS support behind
> it (be that test infra for the existing django-mssql fork etc) is already
> the icing on the cake.
>
> Cheers,
> Florian
>
>
> On Friday, December 4, 2020 at 2:59:43 AM UTC+1 vwa...@gmail.com wrote:
>
>> Thanks for the responses.
>>
>> @Florian - I've now reached out to the maintainers of ESSolutions as well
>> as the relevant previous Microsoft engagement owners, thanks for the
>> suggestion
>>
>> @Chris - This is excellent news indeed, we are excited to make progress
>> beginning with some small steps
>>
>> @r...@whidbey.com -
>> A) django-mssql is viewed as the Phase 1 focus and current preferred
>> option with a longer term Phase 2 goal of including MSSQL as a supported
>> backend for Django core
>> B) I've now logged both your pain points as issues in our private repo
>> (which will be made public after internal compliance reviews)
>> C) Happy to hear about your scaled production app using Django and MSSQL.
>> Could I ask you to send a "Hello" email to myself at
>> v-wa...@microsoft.com, so that we can follow up with eventual testing?
>>
>> @dans...@gmail.com - Your security concerns are important and noted,
>> I've flagged this for investigation as a priority
>>
>> Cheers,
>> Warren
>> On Friday, 27 November 2020 at 10:57:09 UTC-8 dans...@gmail.com wrote:
>>
>>> I'd suggest someone talk with professional DBAs for MSSQL.  In my work,
>>> which is Federal government, the DBA told me that disconnecting from PSQL
>>> as "appuser" and attempting to connect to database "postgres" in order to
>>> create the test database violated FISMA.  I had to subclass my own
>>> postgresql backend to create the test user while connected to my actual
>>> database.  I would imagine that the original reasons for doing it this way
>>> harkens back to a time when people used the same database server for
>>> production, staging, qa, and integration, and some of these environments
>>> may not have existed. While in some organizations we have only production,
>>> staging/qa, and development/integration, I would guess there are few cases
>>> where the same database server is used for production and the other
>>> environments.
>>>
>>> On Fri, Nov 27, 2020 at 1:18 PM r...@whidbey.com 
>>> wrote:
>>>
 Good news.  I've been using Django on MSSQL for about 8 years.  Couple
 of things:
 - I've been using pyodbc, not django-mssql.  I note your messages from
 2015 include it as a library to check for compatibility; what was the
 outcome of that?  Is it proposed that django-mssql become the
 "best-practices" interface for SQL Server?
 - Couple of persistent pain points:
   1. Testing.  The Django code that sets up test databases fails with
 MSSQL, while it succeeds with PostGRE, MySQL and SQLite.  The issues seem
 to revolve around setting constraints as the tables are generated, rather
 than holding off and enabling the constraints at the end of the process.
   2. Stored Procedures.  These need to be loaded as an additional step
 in the creation of a database, and don't really have any representation in
 Django per se so migrations, etc don't generally have an idea that they
 exist.

 I'd be happy to test out what you come up with against our system.
 It's currently serving