Re: Autocomplete fields and cleaned_data

[Florian Apolloner]

On Monday, May 13, 2019 at 8:25:56 PM UTC+2, Melvyn Sopacua | 3YOURMIND 
wrote:
>
> It seemingly removes the field from self.cleaned_data, which means we can 
> no longer validate it.
>

If that is the case it is a bug I'd say. 

-- 
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/c7fe8e55-a39d-4dee-a13f-b3a683397f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Autocomplete fields and cleaned_data

[Melvyn Sopacua | 3YOURMIND]

I'm currently looking at a bug in our application, caused by
autocomplete_fields on a ModelAdmin. It seemingly removes the field from
self.cleaned_data, which means we can no longer validate it.

I can reproduce this by removing/adding the field from/to
autocomplete_fields and resubmitting the form after re-rendering. This is a
vanilla manytomany relation.

So now I wonder if this is an implementation bug in Django, with us
(something else I'm not considering) or documentation bug, as none of this
is mentioned in the documentation on either concepts.

I'm happy to file a bug report and classify it according to the above if it
is a bug. Otherwise, I'll dive down the rabbit hole.
-- 

*Backend Developer*

Mobile: +49 (0)160 179 6874
eMail: m...@3yourmind.com
Web: www.3yourmind.com


-- 


The information that has been provided should be regarded as confidential 
within the context of our non-disclosure agreement.

 

3YOURMIND GmbH


Bismarckstraße 10-12 | 10625 Berlin | Germany

 

VAT ID - USt-IdNr. gemäß 
§ 27 a Umsatzsteuergesetz: DE296555110

Company with its registered seat in 
- Sitz der Gesellschaft: Berlin



Register court - Registergericht: 
Amtsgericht Charlottenburg (Berlin)

-- 
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/CAF5kSxRx92R0S9kdtZrZANmhCjomsWy-zp85%3DO%2Bw_WicB259BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to deal with potential Django bugs you come accross

[Curtis Maloney]

Hi Erik,


On 5/13/19 8:22 PM, Erik Stein wrote:


Hello everyone --

 From time to time I come accross a potential bug in Django core, but 
because of a tight schedule don't have the time to dive into it and 
write a proper ticket. How would you suggest to deal with it?



my personal position would be to open a ticket with what information you 
_do_ have, so the discovery is not lost.


The "worst case" is one of the ever efficient Django Fellows comes by, 
tests it out, and closes it as "works as expected".


If you _don't_ log the issue, it _will_ be forgotten about, because 
we're all human. :)



Today e.g.

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any 
backtrace in production mode.


This was caused by a buggy 404.html template, but probably buggy 404 
templates should give a backtrace, too, and i18n_patterns shouldn't be 
concerned by this anyway.


Certainly a solution worthy of discussion!

Are those notes something which should get into Trac to be investigated 
later?


Absolutely yes!


Thanks for you opinion and guidance,


--
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/f91ecd30-a077-956c-a5af-1027359c65f2%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Internals

[Aymeric Augustin]

Hello,

I would suggest https://www.youtube.com/watch?v=bgV39DlmZ2U if you'd like
to understand how the ORM is structured in layers.

-- 
Aymeric.

Le lun. 13 mai 2019 à 12:16, Adam Johnson  a écrit :

> Yes there isn't much documented on the ORM internals, but there are other
> resources. The DUTH videos are a great start and inspired me to get started
> contributing to Django. Specifically:
>
>- https://www.youtube.com/watch?v=CGF-0csOjPw
>- https://www.youtube.com/watch?v=-4jhPRfCRSM
>- https://www.youtube.com/watch?v=-1tt0S__kQk
>
> This talk is also on my to-watch list, from James Bennett, he covers a lot
> of internals:
>
>- https://www.youtube.com/watch?v=tkwZ1jG3XgA
>
> As for looking through the code, try looking at django.contrib.postgres
> first - it's interesting as it's all *extensions* to the ORM (custom
> fields, migration operations, etc.) so an easier on ramp than diving into
> the inner code of Query etc. It's what insipred me to make my library
> django-mysql ( https://github.com/adamchainz/django-mysql ) that does the
> same kind of stuff for MySQL/MariaDB.
>
> Then maybe look itno tracing some simple queryset operations, such as
> Foo.objects.all(), and see all the steps that goes through. Understand what
> Query is and how SQLCompiler converts it to SQL that the database backend
> executes.
>
> Hope that helps,
>
> Adam
>
> On Mon, 13 May 2019 at 09:54, Mahdi Zareie  wrote:
>
>> Great, thanks
>>
>> On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote:
>>>
>>> Hi Mahdi,
>>>
>>> I would suggest reading the code and test code in the tests/ directory
>>> for the ORM.
>>>
>>> There might also be some videos from Django Under The Hood conferences,
>>> found some here:
>>>
>>> https://www.google.com/search?q=Django+Under+The+Hood+orm=vid
>>>
>>> Best
>>>
>> --
>> 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/81554698-8fad-4fd0-a534-a566725058b3%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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 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/CAMyDDM00cB5Mz%2Bsec3KpF%3DEF9Z4yXipzMwuag7q%2B5EFA8cch2g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Aymeric.

-- 
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/CANE-7mUixaF76W9MwN_y4ufvT%3D-hMq4PkuwFZVva4UafktOA9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to deal with potential Django bugs you come accross

[Erik Stein]

Hello everyone --

From time to time I come accross a potential bug in Django core, but 
because of a tight schedule don't have the time to dive into it and 
write a proper ticket. How would you suggest to deal with it?


Today e.g.

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any 
backtrace in production mode.


This was caused by a buggy 404.html template, but probably buggy 404 
templates should give a backtrace, too, and i18n_patterns shouldn't be 
concerned by this anyway.


Are those notes something which should get into Trac to be investigated 
later?


Thanks for you opinion and guidance,

-- erik


--
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/6e03157c-770a-cfe6-1569-e0f0c2aee122%40classlibrary.net.
For more options, visit https://groups.google.com/d/optout.

(improvement) makemigrations app_label can and should always create migration only for this app_label

[nnseva]

Hi All,

The %subj% is a discussion for the ticket 
https://code.djangoproject.com/ticket/30467

The theme has been touched also in the following threads:
https://groups.google.com/forum/#!searchin/django-developers/makemigrations$20dependency%7Csort:date/django-developers/WgFacUFvgfs/cDoYO018NzIJ
https://groups.google.com/forum/#!searchin/django-developers/makemigrations|sort:date/django-developers/iClIpvwlbAU/53ZBk-y_AgAJ
https://groups.google.com/forum/#!searchin/django-developers/makemigrations|sort:date/django-developers/IG5ZSRRp8Rw/a0VSjrJMAQAJ

*What happens?*

Now, if the makemigration is running for the only app_label A, it sometimes 
tries to create a migration for other app_label B implicitly, if the A 
contains a *ForeignKey* field referring a model in the B with the 
unsynchronized state.

*What proposed?*

Always avoid implicit migration creation for the referred application B.

*Why the makemigrations CAN always do it?*

If the application A has a *ForeinKey* reference to the application B *without 
migrations*, it means, that all tables in the application B are already 
created on the stage of initial migration and need not be migrated.

If the *ForeignKey* in the application A refers to the *existent* (in the 
migration state) model of the application B, but with the *not synchronized 
state*, the created migration may depend on the last existent migration of 
the application A instead of newly created one almost anyway.

The only *inconsistent* unsynchronized change leading to possible errors 
may be:
- changing the *primary key* of the referred model in application B
- creating a *brand new referred model* in application B

Change in the primary key leads to changes in the ForeignKey field 
attributes, implicit, or explicit. Such a change may be detected separately 
and *agnostic* way: determining changes only in the ForeignKey field 
attribute values.
Non-existent referred model in the state can also be detected easy, and 
leads to other error detected on the stage of migration itself, or while 
runtime (non-existent table for the model).

Such an *inconsistent* unsynchronized change may lead to *error message* 
generated by the `makemigrations A`, like `the application A refers to the 
application B which needs to have synchronized migration state, please 
create a migration for B first`.

*Why the makemigrations SHOULD always do it?*

What is application B? It may be:

- own project application
- third-party application

If application B is own project application, the project owner always can 
explicitly create a new migration for the application B to synchronize its 
state. Such a way, it is enough to have an *error message* such described 
above instead of *implicit creation* of such a migration creating migration 
for application A.

The most problem is a third-party application.

The third-party application is such a thing that should not be changed by 
the programmer. It is installed in the system area or virtual environment 
as a rule.

If the third-party application B is installed into the system area, the 
`makemigration A` command will lead to file access error if tries to create 
a migration for application B automatically.
If the third-party application B is installed into the virtual environment, 
the `makemigration A` command will lead to migration conflict, and/or refer 
to non-existent migration in case of shared development of the project.

*Why the third-party application may have inconsistent migration state?*

1. Of course, the third-party application B can *really* have *inconsistent* 
migration state because of third-party programmers *error*. If such a 
problem is *significant* for the project, it is *detected* by the error 
message described above, or others, which allow the programmer of the 
project to make an *explicit decision*, what to do next.

The project programmer can create a lost (temporary) migration for 
application B, it is a resolution compatible with the existent now. He also 
can avoid using this application at all, create an issue in the tracker, 
etc... Anyway, the programmer makes a decision *explicitly* and knows about 
all the effects of it.

2. The inconsistent migration state may also be caused by dependencies of 
settings, different in the application when migration for B has been 
created, and project when the migration for A is created.

Such a dependency may lead to insignificant changes in the model state 
which don't change *ForeignKey* attributes. It might be changing in field 
verbose name, enum field choices, file field storage, or other field 
attributes not related to the database table metadata state.

Unfortunately, even the solution with the *__eq__ *substitution described 
in the documentation does not work to avoid unnecessary migration detection 
in such a case. A field attribute value of the complex deconstructible type 
leads to wrong state inconsistency detection when changed, even when have 
an *__eq__* 

Re: Django ORM Internals

[Adam Johnson]

Yes there isn't much documented on the ORM internals, but there are other
resources. The DUTH videos are a great start and inspired me to get started
contributing to Django. Specifically:

   - https://www.youtube.com/watch?v=CGF-0csOjPw
   - https://www.youtube.com/watch?v=-4jhPRfCRSM
   - https://www.youtube.com/watch?v=-1tt0S__kQk

This talk is also on my to-watch list, from James Bennett, he covers a lot
of internals:

   - https://www.youtube.com/watch?v=tkwZ1jG3XgA

As for looking through the code, try looking at django.contrib.postgres
first - it's interesting as it's all *extensions* to the ORM (custom
fields, migration operations, etc.) so an easier on ramp than diving into
the inner code of Query etc. It's what insipred me to make my library
django-mysql ( https://github.com/adamchainz/django-mysql ) that does the
same kind of stuff for MySQL/MariaDB.

Then maybe look itno tracing some simple queryset operations, such as
Foo.objects.all(), and see all the steps that goes through. Understand what
Query is and how SQLCompiler converts it to SQL that the database backend
executes.

Hope that helps,

Adam

On Mon, 13 May 2019 at 09:54, Mahdi Zareie  wrote:

> Great, thanks
>
> On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote:
>>
>> Hi Mahdi,
>>
>> I would suggest reading the code and test code in the tests/ directory
>> for the ORM.
>>
>> There might also be some videos from Django Under The Hood conferences,
>> found some here:
>>
>> https://www.google.com/search?q=Django+Under+The+Hood+orm=vid
>>
>> Best
>>
> --
> 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/81554698-8fad-4fd0-a534-a566725058b3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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 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/CAMyDDM00cB5Mz%2Bsec3KpF%3DEF9Z4yXipzMwuag7q%2B5EFA8cch2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Internals

[Mahdi Zareie]

Great, thanks

On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote:
>
> Hi Mahdi,
>
> I would suggest reading the code and test code in the tests/ directory for 
> the ORM.
>
> There might also be some videos from Django Under The Hood conferences, 
> found some here:
>
> https://www.google.com/search?q=Django+Under+The+Hood+orm=vid
>
> Best
>

-- 
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/81554698-8fad-4fd0-a534-a566725058b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Internals

[J. Pic]

Hi Mahdi,

I would suggest reading the code and test code in the tests/ directory for
the ORM.

There might also be some videos from Django Under The Hood conferences,
found some here:

https://www.google.com/search?q=Django+Under+The+Hood+orm=vid

Best

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

Re: Introduction

[Ruchit Vithani]

I'm working now on ticket #30463 
, and I've figured out what 
the problem is. Here, when self._meta_ordering is called, it returns 
instances of OrderBy type and, when .join is called on that list, it throws 
an error saying: expected str instance but OrderBy found. One easy solution 
is already mentioned in the ticket, which suggests using "', '".join*([*str
*(*f*)* for f in self._meta_ordering*]**).  *But this causes a problem 
since we don't want quotes around OrderBy, and we do want quotes around 
anything inside F(), (i.e we want F('anything')). Moreover, we can not use ", 
".join instead of "', '".join  since we also want quotes around items if 
query expression is not used. 

So, the simple solution which came to my mind after thinking for some time 
was, to call one more string method on "', '".join*([*str*(*f*)* for f 
in self._meta_ordering*]**), * to replace `OrderBy with OrderBy and )' with 
). I'm not sure this is a cleaner solution to this problem, but any other 
solution did not come to my mind. Also, there will be a problem in 
replacement of F( ) with F(' '). I think we'll need to use regular 
expressions in this replacement. 

Any thoughts or comments on my solution? Or is there any better solution 
anyone can think of about this ticket?

-- 
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/a4762531-dd0c-4ece-9d8e-b07a35e2b7e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.