Re: Django : Change Backend as mysql and create sample example using django ORM

[Raghavendrachari k]

Hi Sonali,
Could you please paste the models.py file ??
Might be there is some syntax error in the models you have created.
Regards,
Raghav

On Tue, Aug 28, 2018 at 9:41 PM parmeshwar deharkar <
parmeshwardehar...@gmail.com> wrote:

> hi sonali
>  you install sql libray in your project package then edit the setting.py
> file at django framework with database .
> I hope your problem will be solve...
>
> On Mon, Aug 27, 2018 at 4:54 PM Sonali Vighne 
> wrote:
>
>> Hi,
>> I have tried a lot to change Django back-end as MySQL but not able to
>> achieve this.
>> please help for the same.
>>
>> thanks in advance. :)
>>
>>
>> --
>> 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/2c673679-4532-4147-a072-5b712b62a621%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAFyF%2BQg5LcYkXWygyhdu03ciqYUBMifNBWnS923Mstq8jfTnLA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAHjM6E5Ky9BDUFi4V887V%2BkMasb6%2BZJ8V7nHKCYqgeUAun0FQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not Creating test DBs with PG backend

[Curtis Maloney]

On 08/28/2018 08:33 PM, Tim Graham wrote:

Why is a new option needed? Why can't --keepdb be used for this use case?


Because that would be different behavior.

If you can convince me that using --keepdb is a solution, then I will 
use your argument to say that --keepdb should be on always.


What I'm looking to offer users is to create and clean up objects in the 
test DB, separate from create/drop test DB.


However, I want to do this in a way that doesn't weaken the existing 
protection for "Oops, we're trying to use a test DB that already 
exists... did you make a mistake?  We don't want to trounce real data."


--
Curtis

--
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/a2f93f80-ff4d-9082-76c4-2f186a3b9a7a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels doesn’t conform to Django middleware specifications

[Andrew Godwin]

Just to say that I've reopened the original issue in question as it's clear
now this needs to be fixed. I won't be able to get to writing a fix for a
bit, though, so if someone else wants to they should.

Andrew

On Tue, Aug 28, 2018 at 5:41 AM John Obelenus  wrote:

> Just finished reading both bug reports and I see the file loader lookup in
> whitenoise. This explains a lot actually. We are still on Channels 1, and
> when we tried an upgrade to Channels 2, but encountered terrible
> performance at load and had to undo it.
>
> On Tuesday, August 28, 2018 at 8:00:17 AM UTC-4, John Obelenus wrote:
>>
>> Can I ask a dumb question? Why did you only discover this with adding
>> Whitenoise, and not the default/common middleware stack that comes in
>> django? Asking that question in another way: What is specific to whitenoise
>> that this constant loading of middleware causes such a perf hit? This
>> question in no way implies this should not be fixed, its just my curiosity
>> (I'm in the exact same situation of running channels and whitenoise)
>>
>> On Monday, August 27, 2018 at 12:46:15 PM UTC-4, Carl-Philip Majgaard
>> wrote:
>>>
>>> After some digging, I was able to find the reason for why adding the
>>> Whitenoise middleware to my Channels-enabled project was causing a massive
>>> performance drop.
>>>
>>>
>>> It appears that for every inbound HTTP request, Channels initializes a
>>> new AsgiHandler. In turn, this means that the entire middleware stack is
>>> being loaded for every HTTP request. See below:
>>>
>>>
>>> https://github.com/django/channels/blob/master/channels/routing.py#L45-L62
>>>
>>> https://github.com/django/channels/blob/master/channels/http.py#L157-L183
>>>
>>>
>>> This has two consequences:
>>>
>>>1. Channels is causing middleware to fall out of conformity with
>>>Django documentation, which states that middleware’s __init__() is only
>>>called *once*, on server startup.
>>>2. Any middleware which performs more-than-trivial work in its
>>>__init__() causes massive latency on any incoming request.
>>>
>>>
>>> The issue was diagnosed in:
>>>
>>> https://github.com/django/channels/issues/1099
>>>
>>> https://github.com/django/channels/issues/1121
>>>
>>>
>>> In response to the diagnosis in django/channels #1121, Andrew Godwin
>>> says:
>>>
>>> Hmm, ASGI middleware is loaded every request (#1099
>>> ) so it's quite
>>> possible I made the same mistake with the Django middleware as the handler
>>> is loaded every request too. If so, someone should be able to patch that
>>> quite easily.
>>>
>>>
>>> However, I feel that a patch to this issue would be non-trivial to
>>> create.
>>>
>>>
>>> If the AsgiHandler is refactored such that it receives *scope* upon
>>> __call__() rather than on __init__() (and is only initialized once)*, *it
>>> no longer conforms to the tests defined in
>>> https://github.com/django/asgiref/blob/master/asgiref/testing.py#L17,
>>> as they require passing scope for initialization. Thus, the AsgiHandler
>>> would no longer fit the shape of an Asgi Application.
>>>
>>>
>>> I would attempt a fix for this, but I am unsure of how to approach it
>>> given the constraints of the problem.
>>>
>>> Perhaps someone more knowledgeable about Channels could chime in with
>>> their $0.02? I would love to devote some time to fixing this, but need some
>>> input before I do.
>>>
>>>
>>>
>>> --
> 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/998d7855-152e-4bc1-b2f2-8fd0f80099b4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFwN1uqyC6a1p0pKRv%2Brh9ZTwYyyu_Q4S7OgvSOfghdSdqCZng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django : Change Backend as mysql and create sample example using django ORM

[parmeshwar deharkar]

hi sonali
 you install sql libray in your project package then edit the setting.py
file at django framework with database .
I hope your problem will be solve...

On Mon, Aug 27, 2018 at 4:54 PM Sonali Vighne 
wrote:

> Hi,
> I have tried a lot to change Django back-end as MySQL but not able to
> achieve this.
> please help for the same.
>
> thanks in advance. :)
>
>
> --
> 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/2c673679-4532-4147-a072-5b712b62a621%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFyF%2BQg5LcYkXWygyhdu03ciqYUBMifNBWnS923Mstq8jfTnLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help wanted testing proposal for the Migration Graph algorithm

[dan]

Hi Carlton,

Adam asked me to take a look at this. I've run it on our codebase with 
~1100 migrations and ~380 apps.

Running on Django 2.1, the results of this script (the updated version) are:

> 1min 23s ± 1.1 s per loop (mean ± std. dev. of 7 runs, 1 loop each)


Running on the branch, installed with [1], the results are:

> 1min 20s ± 524 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

There were no exceptions thrown - the script completed cleanly, although I 
haven't actually migrated with it or checked that the migrations work. I 
assume the script is enough to ensure consistent migrations? Around a 3.5% 
speedup.

I hope this is what you were looking for, apologies if I've got something 
wrong - I'm lacking full context on this. Hope this helps!


Dan


[1]: pip install 
https://github.com/monoidal/django/archive/optimize_migrations.zip




On Monday, 20 August 2018 10:54:29 UTC+1, Carlton Gibson wrote:
>
> Making the script less noisy here I commented out the actual work.
> (So it didn't function as a test.) 
> (No comment. )
>
> Corrected version:
>
> ```
> import sys
>
> from django.db import connection
> from django.db.migrations.loader import MigrationLoader
>
> loader = MigrationLoader(connection)
>
> backwards = loader.graph.root_nodes()
> forwards = loader.graph.leaf_nodes()
>
> print('Calculating backward plans:')
> for root in backwards:
> loader = MigrationLoader(connection)
> sys.stdout.write('.')
> plan = loader.graph.backwards_plan(root)
> #print(plan)
> sys.stdout.write('\n')
> print('Calculating forward plans:')
> for leaf in forwards:
> loader = MigrationLoader(connection)
> sys.stdout.write('.')
> plan = loader.graph.forwards_plan(leaf)
> # print(plan)
>
> sys.stdout.write('\nRun Done\n\n')
>
> ```
>

-- 
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/cab6baa9-bb5f-42c7-be8b-0223b36cf826%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels doesn’t conform to Django middleware specifications

[John Obelenus]

Just finished reading both bug reports and I see the file loader lookup in 
whitenoise. This explains a lot actually. We are still on Channels 1, and 
when we tried an upgrade to Channels 2, but encountered terrible 
performance at load and had to undo it.

On Tuesday, August 28, 2018 at 8:00:17 AM UTC-4, John Obelenus wrote:
>
> Can I ask a dumb question? Why did you only discover this with adding 
> Whitenoise, and not the default/common middleware stack that comes in 
> django? Asking that question in another way: What is specific to whitenoise 
> that this constant loading of middleware causes such a perf hit? This 
> question in no way implies this should not be fixed, its just my curiosity 
> (I'm in the exact same situation of running channels and whitenoise)
>
> On Monday, August 27, 2018 at 12:46:15 PM UTC-4, Carl-Philip Majgaard 
> wrote:
>>
>> After some digging, I was able to find the reason for why adding the 
>> Whitenoise middleware to my Channels-enabled project was causing a massive 
>> performance drop. 
>>
>>
>> It appears that for every inbound HTTP request, Channels initializes a 
>> new AsgiHandler. In turn, this means that the entire middleware stack is 
>> being loaded for every HTTP request. See below:
>>
>> https://github.com/django/channels/blob/master/channels/routing.py#L45-L62
>>
>> https://github.com/django/channels/blob/master/channels/http.py#L157-L183
>>
>>
>> This has two consequences:
>>
>>1. Channels is causing middleware to fall out of conformity with 
>>Django documentation, which states that middleware’s __init__() is only 
>>called *once*, on server startup.  
>>2. Any middleware which performs more-than-trivial work in its 
>>__init__() causes massive latency on any incoming request. 
>>
>>
>> The issue was diagnosed in:
>>
>> https://github.com/django/channels/issues/1099
>>
>> https://github.com/django/channels/issues/1121
>>
>>
>> In response to the diagnosis in django/channels #1121, Andrew Godwin says:
>>
>> Hmm, ASGI middleware is loaded every request (#1099 
>> ) so it's quite possible 
>> I made the same mistake with the Django middleware as the handler is loaded 
>> every request too. If so, someone should be able to patch that quite easily.
>>
>>
>> However, I feel that a patch to this issue would be non-trivial to create.
>>  
>>
>>
>> If the AsgiHandler is refactored such that it receives *scope* upon 
>> __call__() rather than on __init__() (and is only initialized once)*, *it 
>> no longer conforms to the tests defined in 
>> https://github.com/django/asgiref/blob/master/asgiref/testing.py#L17, as 
>> they require passing scope for initialization. Thus, the AsgiHandler would 
>> no longer fit the shape of an Asgi Application. 
>>
>>
>> I would attempt a fix for this, but I am unsure of how to approach it 
>> given the constraints of the problem. 
>>
>> Perhaps someone more knowledgeable about Channels could chime in with 
>> their $0.02? I would love to devote some time to fixing this, but need some 
>> input before I do.
>>
>>
>>
>>

-- 
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/998d7855-152e-4bc1-b2f2-8fd0f80099b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels doesn’t conform to Django middleware specifications

[John Obelenus]

Can I ask a dumb question? Why did you only discover this with adding 
Whitenoise, and not the default/common middleware stack that comes in 
django? Asking that question in another way: What is specific to whitenoise 
that this constant loading of middleware causes such a perf hit? This 
question in no way implies this should not be fixed, its just my curiosity 
(I'm in the exact same situation of running channels and whitenoise)

On Monday, August 27, 2018 at 12:46:15 PM UTC-4, Carl-Philip Majgaard wrote:
>
> After some digging, I was able to find the reason for why adding the 
> Whitenoise middleware to my Channels-enabled project was causing a massive 
> performance drop. 
>
>
> It appears that for every inbound HTTP request, Channels initializes a new 
> AsgiHandler. In turn, this means that the entire middleware stack is being 
> loaded for every HTTP request. See below:
>
> https://github.com/django/channels/blob/master/channels/routing.py#L45-L62
>
> https://github.com/django/channels/blob/master/channels/http.py#L157-L183
>
>
> This has two consequences:
>
>1. Channels is causing middleware to fall out of conformity with 
>Django documentation, which states that middleware’s __init__() is only 
>called *once*, on server startup.  
>2. Any middleware which performs more-than-trivial work in its 
>__init__() causes massive latency on any incoming request. 
>
>
> The issue was diagnosed in:
>
> https://github.com/django/channels/issues/1099
>
> https://github.com/django/channels/issues/1121
>
>
> In response to the diagnosis in django/channels #1121, Andrew Godwin says:
>
> Hmm, ASGI middleware is loaded every request (#1099 
> ) so it's quite possible 
> I made the same mistake with the Django middleware as the handler is loaded 
> every request too. If so, someone should be able to patch that quite easily.
>
>
> However, I feel that a patch to this issue would be non-trivial to create.
>  
>
>
> If the AsgiHandler is refactored such that it receives *scope* upon 
> __call__() rather than on __init__() (and is only initialized once)*, *it 
> no longer conforms to the tests defined in 
> https://github.com/django/asgiref/blob/master/asgiref/testing.py#L17, as 
> they require passing scope for initialization. Thus, the AsgiHandler would 
> no longer fit the shape of an Asgi Application. 
>
>
> I would attempt a fix for this, but I am unsure of how to approach it 
> given the constraints of the problem. 
>
> Perhaps someone more knowledgeable about Channels could chime in with 
> their $0.02? I would love to devote some time to fixing this, but need some 
> input before I do.
>
>
>
>

-- 
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/5c483259-6759-45cc-a8fd-e90ace9e6bdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Django : Change Backend as mysql and create sample example using django ORM

[Sonali Vighne]

I will paste full error and stack trace here.
This is occurred when I am giving “python manage.py migrate” command

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Traceback (most recent call last):
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 83, in _execute
return self.cursor.execute(sql)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\mysql\base.py",
 line 71, in execute
return self.cursor.execute(query, args)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 250, in execute
self.errorhandler(self, exc, value)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\connections.py",
 line 50, in defaulterrorhandler
raise errorvalue
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 247, in execute
res = self._query(query)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 411, in _query
rowcount = self._do_query(q)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 374, in _do_query
db.query(q)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\connections.py",
 line 277, in query
_mysql.connection.query(self, query)
_mysql_exceptions.ProgrammingError: (1064, "You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version for the 
right syntax to use near '(6) NOT NULL)' at line 1")

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\migrations\recorder.py",
 line 55, in ensure_schema
editor.create_model(self.Migration)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\base\schema.py",
 line 312, in create_model
self.execute(sql, params or None)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\base\schema.py",
 line 133, in execute
cursor.execute(sql, params)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 100, in execute
return super().execute(sql, params)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 68, in execute
return self._execute_with_wrappers(sql, params, many=False, 
executor=self._execute)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 77, in _execute_with_wrappers
return executor(sql, params, many, context)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 85, in _execute
return self.cursor.execute(sql, params)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\utils.py",
 line 89, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\utils.py",
 line 83, in _execute
return self.cursor.execute(sql)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\django\db\backends\mysql\base.py",
 line 71, in execute
return self.cursor.execute(query, args)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 250, in execute
self.errorhandler(self, exc, value)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\connections.py",
 line 50, in defaulterrorhandler
raise errorvalue
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 247, in execute
res = self._query(query)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 411, in _query
rowcount = self._do_query(q)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\cursors.py",
 line 374, in _do_query
db.query(q)
  File 
"C:\Users\sonali_vighne\AppData\Local\Programs\Python\Python36\lib\site-packages\MySQLdb\connections.py",
 line 277, in query
_mysql.connection.query(self, query)
django.db.utils.ProgrammingError: (1064, "You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for the right 

Re: Not Creating test DBs with PG backend

[Tim Graham]

Why is a new option needed? Why can't --keepdb be used for this use case?

On Tuesday, August 28, 2018 at 2:23:52 AM UTC-4, Curtis Maloney wrote:
>
> Greetings, 
>
> one problem that turns up more and more frequently, it seems, is that 
> someone is trying to run tests but can't because of the following 
> scenario: 
>
> 1. The user they connect to the DB using a role that does NOT have 
> permission to create a DB 
>
> 2. Django's PG adapter, when keepdb is not set, will attempt to create 
> the DB 
>
> 3. If the create fails, and NOT with the error of "duplicate DB name", 
> KABOOM. 
>
> The error they get is that the user does not have permission to create 
> DBs, since permissions are checked before testing if the name exists. 
>
> Instead, I'm trying to leverage the existing _database_exists check used 
> by keepdb. 
>
> My initial attempt checked if the DB exists and, if it does, issues a 
> "DROP OWNED BY CURRENT_USER;" instead of calling _execute_create_test_db. 
>
> Of course, this failed the tests, and rightly so. This obliterates the 
> protection of connecting to the wrong DB... and, in fact, makes that 
> mistake far FAR more damaging. 
>
> So I'm looking for input on what might be the best direction moving 
> forward: 
>
> 1. wrangle a new option to say "use existing" ... to allow using an 
> existing DB if it exists. 
>
> 2. prompt the user to confirm they want to use the existing DB... and 
> perhaps prompt a second time to confirm they want to DROP OWNED BY... 
>
> 3. some other option? 
>
> The first option, at least, will possibly require more invasive changes, 
> since higher levels of the code make assumptions about 
> _execute_create_test_db and when it will succeed / raise exception. 
>
> -- 
> Curtis 
>

-- 
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/a864f570-cd35-40d6-86e0-b2ef7a32e1f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Privacy in Django (GDPR)

[Vasili Korol]

I outlined the problem of parent domain cookies included in Django's error 
reports, which may be a problem due to GDPR.
There's a ticket in the Django bugtracker:  
 https://code.djangoproject.com/ticket/29714
And a discussion in the 'developers' 
group:  https://groups.google.com/forum/#!topic/django-developers/rABXPO-xVAo

So far, the proposed solution is to implement better customization of error 
reports, which would allow disabling the inclusion of cookies.

-- 
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/169637fd-a8cf-463b-9f82-a9ffa1d93d39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Not Creating test DBs with PG backend

[Curtis Maloney]

Greetings,

one problem that turns up more and more frequently, it seems, is that 
someone is trying to run tests but can't because of the following scenario:


1. The user they connect to the DB using a role that does NOT have 
permission to create a DB


2. Django's PG adapter, when keepdb is not set, will attempt to create 
the DB


3. If the create fails, and NOT with the error of "duplicate DB name", 
KABOOM.


The error they get is that the user does not have permission to create 
DBs, since permissions are checked before testing if the name exists.


Instead, I'm trying to leverage the existing _database_exists check used 
by keepdb.


My initial attempt checked if the DB exists and, if it does, issues a 
"DROP OWNED BY CURRENT_USER;" instead of calling _execute_create_test_db.


Of course, this failed the tests, and rightly so. This obliterates the 
protection of connecting to the wrong DB... and, in fact, makes that 
mistake far FAR more damaging.


So I'm looking for input on what might be the best direction moving forward:

1. wrangle a new option to say "use existing" ... to allow using an 
existing DB if it exists.


2. prompt the user to confirm they want to use the existing DB... and 
perhaps prompt a second time to confirm they want to DROP OWNED BY...


3. some other option?

The first option, at least, will possibly require more invasive changes, 
since higher levels of the code make assumptions about 
_execute_create_test_db and when it will succeed / raise exception.


--
Curtis

--
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/3b1324e9-c3c1-6ae6-491b-3c9d9c5be47f%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.