Re: "Unify by values" setting in Oracle's base.py

[NPB]

Hi Mariusz and Simon,

Yes, agreed, it is true that Oracle doesn't support column aliases in GROUP 
BY. It is possible to use "GROUP BY ", but only if a 
specific Oracle session parameter setting is used. IMO it would be 
undesirable to make this setting mandatory for Django, though.

Oracle definitely deals well with the example I gave, and the optimizer is 
very good at avoiding performance regressions when it is used (provided 
that optimizer transformations such as simple view merging are not 
disabled). It is, after all, an easy transformation to spot and 
transformations are applied even in very complex cases of course. IMHO, the 
effect on query performance is unlikely to be a significant concern.  

Tuning Oracle cursor sharing is something I've considered, but there is no 
solution in cases where bind variable names are used and are jumbled. Each 
version of the SQL statement will be hard parsed (rather than soft parsed) 
and a new cursor will be created. Sadly, the performance implications of 
this are almost always underestimated; probably because they don't become 
apparent until the application feels some heat. I don't want to over-state 
the issue too much though - when I say "some heat" I really mean 
"significant heat", but as a long-term Oracle user it is a no-brainer to 
empower cursor sharing to do its part in making sure that the database runs 
smoothly all the way up to machine/VM limits.

Regards,
Nigel.
On Tuesday, 13 April 2021 at 06:31:51 UTC+1 Mariusz Felisiak wrote:

> Hi Nigel,
>
> Creating a subquery only looks like a good solution for a limited 
> number of cases. As far as I'm aware it will also change an execution plan 
> and can cause a performance regression in complicated queries. We also 
> cannot group by column aliases on Oracle as proposed in PR14251 
> . You can try to tune cursor 
> sharing 
> 
>  
> but I don't have any advice here. I would be happy to review a patch in 
> this area, so feel-free to prepare an optimization.
>
> Best,
> Mariusz
>

-- 
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/eacf369c-5ac2-4832-8b39-b63452d6ee90n%40googlegroups.com.

Re: "Unify by values" setting in Oracle's base.py

[NPB]

P.S.

I think I will have a stab at creating a solution. I'll run it through the 
queries, aggregation, and aggregation_regress tests.

Thanks,
Nigel

On Tuesday, 13 April 2021 at 13:34:30 UTC+1 NPB wrote:

> Hi Mariusz and Simon,
>
> Yes, agreed, it is true that Oracle doesn't support column aliases in 
> GROUP BY. It is possible to use "GROUP BY ", but only if a 
> specific Oracle session parameter setting is used. IMO it would be 
> undesirable to make this setting mandatory for Django, though.
>
> Oracle definitely deals well with the example I gave, and the optimizer is 
> very good at avoiding performance regressions when it is used (provided 
> that optimizer transformations such as simple view merging are not 
> disabled). It is, after all, an easy transformation to spot and 
> transformations are applied even in very complex cases of course. IMHO, the 
> effect on query performance is unlikely to be a significant concern.  
>
> Tuning Oracle cursor sharing is something I've considered, but there is no 
> solution in cases where bind variable names are used and are jumbled. Each 
> version of the SQL statement will be hard parsed (rather than soft parsed) 
> and a new cursor will be created. Sadly, the performance implications of 
> this are almost always underestimated; probably because they don't become 
> apparent until the application feels some heat. I don't want to over-state 
> the issue too much though - when I say "some heat" I really mean 
> "significant heat", but as a long-term Oracle user it is a no-brainer to 
> empower cursor sharing to do its part in making sure that the database runs 
> smoothly all the way up to machine/VM limits.
>
> Regards,
> Nigel.
> On Tuesday, 13 April 2021 at 06:31:51 UTC+1 Mariusz Felisiak wrote:
>
>> Hi Nigel,
>>
>> Creating a subquery only looks like a good solution for a limited 
>> number of cases. As far as I'm aware it will also change an execution plan 
>> and can cause a performance regression in complicated queries. We also 
>> cannot group by column aliases on Oracle as proposed in PR14251 
>> . You can try to tune cursor 
>> sharing 
>> 
>>  
>> but I don't have any advice here. I would be happy to review a patch in 
>> this area, so feel-free to prepare an optimization.
>>
>> Best,
>> Mariusz
>>
>

-- 
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/930b8a97-be73-485e-bcea-fa72dc5576ebn%40googlegroups.com.

Announcement of 4.x Technical Board Election Registration

[Chaim Kirby]

The release last week of Django 3.2 represents the final feature release of 
a major release series of Django. Per DEP-10 

 this 
release triggers the election for the Technical board for the Django 4.x 
release cycle. 

All DSF members are automatically registered electors. 

If you are not a DSF member and would like to apply to vote you need to 
register 
here .

The process of electing a new Technical Board will be:

   - Registration of Electors is open for one week and ending Tuesday April 
   20th, 2021 AoE
   - Registration of Candidates will then be open for one week ending 
   Tuesday April 27th, 2021 AoE
   - On Tuesday May 4th all registered and approved electors will receive 
   an email to the email address they are registered with along with a unique 
   code to be used when voting
   - Voting will be open for one week from May 4th
   - The results of the election will be announced when voting is finished.

If you have any questions about the election please see the post on 
djangoproject for contact details 
https://www.djangoproject.com/weblog/2021/apr/13/technical-board-election-registration/

-- 
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/21371bcb-2836-4cea-b6fa-528ec609fb8en%40googlegroups.com.

Question: django.contrib.gis GDAL support of /vsi*

[Jordi Castells]

Hi,

I'm Jordi, long time user of the Django framework, and a first time poster 
to this mailing list after dabbling a bit into the Django implementation 
for a specific problem in my project.

I found out that the support for GDAL virtual filesystems in Django is 
limited to  `/vsimem/` forced via a constant in 
`django.contrib.gis.gdal.raster.source`

VSI_FILESYSTEM_BASE_PATH = '/vsimem/'

The constant is both used to check if the input string is a virtual 
filesystem raster and to properly create a vsi path if the user sends bytes.

GDAL itself supports more types of virtual filesystems. /vsis3 is the one 
of interest to me in particular, so I monkey patched my local Django to 
just skip that check and accept any /vsi* string inputs with no apparent 
error. 
I cloned the latest main and ran the test suite just in case, but the 
gis_tests don't run by default.

So, I was wondering, is there any reason why django.*.GDALRaster is limited 
to vsimem? And how should I properly enable the `gis_tests` to confirm 
everything works as expected?

Salut!

-- 
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/28a9f093-276f-4c12-9b72-011763731466n%40googlegroups.com.

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

Hi everyone 👋🏻

After a long period of inactivity I'm back at it with the help of Taylor.

As a reminder: 
Here is the ticket: https://code.djangoproject.com/ticket/29843 
Here is the initial PR: https://github.com/django/django/pull/10540

After some experiments and discussions it felt like while the 
implementation might solve the initial problem, it's a bit under the hood 
and will be hard to debug if something goes wrong.
The idea was to inject operations at the time of running `migrate`.

So... we went back to the idea of having hooks during the `makemigrations` 
process instead, so that the operations would be written to the migration 
files, which would make it more explicit and less risky. Here is a first 
draft of how it would look like: https://github.com/django/django/pull/14229
.

1. We know that the `makemigrations` process is complicated, so before we 
invest more time down that path, is there something obvious we might be 
missing?
2. What do you think of this approach with hooks (pre and post 
"add_operation")?
3. Do you think it would be a useful feature for other third party apps as 
well (not just content types and permissions)?

Thank you for your input, stay safe

Arthur & Taylor

On Saturday, October 13, 2018 at 12:56:25 PM UTC-6 petter.s...@gmail.com 
wrote:

> I encountered a similar issue recently, but with auth permissions.
>
> It is described here: https://code.djangoproject.com/ticket/29843
>
> On Wednesday, October 3, 2018 at 1:01:37 PM UTC+2, Marcin Nowak wrote:
>>
>> Hello.
>>
>> There is a huge issue with content types framework. The data is loaded 
>> after every migration (post_migrate signal) automatically, and this 
>> approach is against db data consistency.
>> The biggest problem is with data migrations, which are applied at the 
>> first time (on clean database). Any data migration which depends on some 
>> content types will not insert the data.
>>
>> The sequence looks like this:
>>
>>1. create db
>>2. insert into auth_permission ...  inner join django_content_type ...
>>3. post migrate: insert into django_content_type ...
>>
>>
>> Two things are wrong:
>>
>>- automatic creation of content types
>>- creation of content types after running migrations
>>
>> Solution:
>>
>>- creation of new app should add very first migration, which will add 
>>entry to the content types
>>- create_contentypes handler should be removed from post_migrate 
>>signal
>>
>> Any data migration, which depends on some content types, should be 
>> declared with proper dependency. This will guarantee existence of the 
>> required content type entry.
>>
>>
>> BR,
>> Marcin
>>
>>
>>

-- 
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/9f6f9bf3-ad26-4874-939e-a7ad3e201a98n%40googlegroups.com.

Re: Question: django.contrib.gis GDAL support of /vsi*

[Claude Paroz]

Hi Jordi,

Our GDAL Raster expert is Daniel Wiesmann (https://github.com/yellowcap), 
you may try to ping him somehow so that he can give his lights on the 
subject here.

And how should I properly enable the `gis_tests` to confirm everything 
> works as expected?
>

If you use settings configured  with a spatially-enabled database, the 
gis_tests should run (runtests.py --settings=...).

Claude

-- 
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/cbb15069-7f84-4b53-9eca-a8d4effbb56dn%40googlegroups.com.