Re: Deprecate CICharField, CIEmailField, CITextField

[Silvio]

True, not the end of the world. Just ... another dependency. The NPM world 
has traumatized me. Many thanks for creating that.

If there's nothing that can be done, it's time to move on. But worth 
asking. 

(Interestingly, even with the deprecation, historical migration fields 
still need to be supported, so I think some code has to remain)

On Thursday, February 22, 2024 at 3:13:40 AM UTC-5 Johannes Maron wrote:

> I just say it: The decision certainly had good intentions, but maybe 
> wasn't fully informed. It happens.
>
> But since we don't really have a processed to revert a deprecation, I 
> would recommend using the django-citext package. It's a drop-in replacement 
> with the same license as Django and a corporate sponsor to ensure 
> maintenance.
>
> It takes one pip install and a sed command to replace some imports, and 
> you grab a coffee and forget about it.
>
> Am Do., 22. Feb. 2024 um 01:59 Uhr schrieb Silvio :
>
>> Coming in again now that I've looked at upgrading.
>>
>> @Adam: your post was useful. But can you actually say you prefer the new 
>> approach?
>>
>> But I'm going to be honest, this is a lot of hoops and gotchas. What did 
>> we actually gain by deprecating this? I'm seeing maybe 15-20 lines of code 
>> that will be removed? Maybe a touch of ideological purity?
>>
>> Is it unheard of to cancel plans to deprecate this, since it's still in 
>> the code base?
>>
>> 99% of the use case is for CIEmailField, and 99% of people want this to 
>> be searchable, likely within nested models as Matthew is trying to do.
>>
>> So we took something that worked really well and removed it. I just don't 
>> see the gain.
>>
>> I hope we can change your minds. This is the first deprecation in 15 
>> years of usage that I just can't get behind.
>>
>> On Wednesday, December 20, 2023 at 1:16:01 PM UTC-5 Matthew Graham wrote:
>>
>>> I only started trying to move to collations instead of citext recently, 
>>> and it broke the regex validation as as non deterministic collation can't 
>>> support regex validator, like what, why are we replacing something with an 
>>> alternative that actually cant do the job as a replacement
>>>
>>> On Thu, 21 Dec 2023, 4:59 am gw...@fusionbox.com,  
>>> wrote:
>>>
>>>> This breaks search_fields. I can annotate a deterministic collation for 
>>>> simple fields. I don't understand why I have to do workarounds to get 
>>>> builtin stuff to work. 
>>>>
>>>> There's no workaround I can figure out across joins though. I have 
>>>> `search_fields = ['owners__email']`. Using an annotated field 
>>>> `owners__email_deterministic` fails: django.core.exceptions.FieldError: 
>>>> Unsupported lookup 'email_deterministic' for ForeignKey or join on the 
>>>> field not permitted.
>>>>
>>>> I don't understand why I have to do workarounds to get builtin stuff to 
>>>> work. 
>>>>
>>>> > As you can't index the citext column for LIKE queries, doing these 
>>>> types of searches on any real amount of data is going to be too slow in 
>>>> most cases.
>>>>
>>>> I have 100k users and want to search them in the admin. The unindexed 
>>>> query takes 100ms, which is completely fine for this purpose.
>>>>
>>>> Also, you CAN index a citext column for LIKE queries with pg_trgm.
>>>>  
>>>> On Wednesday, September 6, 2023 at 11:56:49 AM UTC-6 Johannes Maron 
>>>> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> We started creating a 3rd party django-citext package, to ensure 
>>>>> future support of PotsgreSQL's CITEXT extension under a corporate funding.
>>>>> You can find the project here: https://github.com/voiio/django-citext
>>>>>
>>>>> While doing so, I noticed a couple of small things, where I'd love 
>>>>> some clarification to know which way to go:
>>>>>
>>>>>1. Will the CITextExtension stay? It's currently not deprecated, 
>>>>>it's super class implements array support.
>>>>>2. The documentation currently can be misleading. Would you 
>>>>>consider proposals for some changes:
>>>>>   - There is a note about performance considerations, yet I 
>>>>>   couldn't find any. There are some limitations, which rightfully 
>>>>> need to be 
>>>>>   considered when using the citext extensi

Re: Deprecate CICharField, CIEmailField, CITextField

[Silvio]

Coming in again now that I've looked at upgrading.

@Adam: your post was useful. But can you actually say you prefer the new 
approach?

But I'm going to be honest, this is a lot of hoops and gotchas. What did we 
actually gain by deprecating this? I'm seeing maybe 15-20 lines of code 
that will be removed? Maybe a touch of ideological purity?

Is it unheard of to cancel plans to deprecate this, since it's still in the 
code base?

99% of the use case is for CIEmailField, and 99% of people want this to be 
searchable, likely within nested models as Matthew is trying to do.

So we took something that worked really well and removed it. I just don't 
see the gain.

I hope we can change your minds. This is the first deprecation in 15 years 
of usage that I just can't get behind.

On Wednesday, December 20, 2023 at 1:16:01 PM UTC-5 Matthew Graham wrote:

> I only started trying to move to collations instead of citext recently, 
> and it broke the regex validation as as non deterministic collation can't 
> support regex validator, like what, why are we replacing something with an 
> alternative that actually cant do the job as a replacement
>
> On Thu, 21 Dec 2023, 4:59 am gw...@fusionbox.com,  
> wrote:
>
>> This breaks search_fields. I can annotate a deterministic collation for 
>> simple fields. I don't understand why I have to do workarounds to get 
>> builtin stuff to work. 
>>
>> There's no workaround I can figure out across joins though. I have 
>> `search_fields = ['owners__email']`. Using an annotated field 
>> `owners__email_deterministic` fails: django.core.exceptions.FieldError: 
>> Unsupported lookup 'email_deterministic' for ForeignKey or join on the 
>> field not permitted.
>>
>> I don't understand why I have to do workarounds to get builtin stuff to 
>> work. 
>>
>> > As you can't index the citext column for LIKE queries, doing these 
>> types of searches on any real amount of data is going to be too slow in 
>> most cases.
>>
>> I have 100k users and want to search them in the admin. The unindexed 
>> query takes 100ms, which is completely fine for this purpose.
>>
>> Also, you CAN index a citext column for LIKE queries with pg_trgm.
>>  
>> On Wednesday, September 6, 2023 at 11:56:49 AM UTC-6 Johannes Maron wrote:
>>
>>> Hi again,
>>>
>>> We started creating a 3rd party django-citext package, to ensure future 
>>> support of PotsgreSQL's CITEXT extension under a corporate funding.
>>> You can find the project here: https://github.com/voiio/django-citext
>>>
>>> While doing so, I noticed a couple of small things, where I'd love some 
>>> clarification to know which way to go:
>>>
>>>1. Will the CITextExtension stay? It's currently not deprecated, 
>>>it's super class implements array support.
>>>2. The documentation currently can be misleading. Would you consider 
>>>proposals for some changes:
>>>   - There is a note about performance considerations, yet I 
>>>   couldn't find any. There are some limitations, which rightfully need 
>>> to be 
>>>   considered when using the citext extension.
>>>   - The deprecation hint towards collations. However, as previously 
>>>   explained, they are by no means an equal replacement. Would you 
>>> accept a 
>>>   reference to a named or unnamed 3rd party solution for future support 
>>> of 
>>>   the citext extension.
>>>3. Finally, Django's admin or rather lookups, don't play 
>>>particularly nice with collations. Something to consider in the 
>>> deprecation 
>>>process.
>>>
>>>
>>> I am happy to get some feedback, especially on the extension and array 
>>> support, since we haven't implemented that yet.
>>> If you have any other pointers, feel free to leave an issue report.
>>>
>>> Thanks!
>>> Joe
>>>
>>>
>>> On Fri, May 12, 2023 at 5:19 PM Johannes Maron  
>>> wrote:
>>>
 Hi,

 Yes, I hope Django will continue to expand expression support. I worked 
 so hard on the SQL compiler to facilitate those kinds of features.
 Anyhow, since db collations are not an adequate replacement for CI 
 text, we will create an open-source backport of the CITEXT fields.
 Once we are done, I will open a PR to alter the documentation, to point 
 towards this option. This should allow users to choose, and will probably 
 easy migration to Django 5 for some.

 But first, I gotta play Tears of the Kindom….

 Cheers!
 Joe


 On Fri, May 12, 2023 at 1:37 PM 'Adam Johnson' via Django developers 
 (Contributions to Django itself)  wrote:

>
> What I am struggling now with is whenever I specify 
>> `db_collation="case_insensitive"` on the field and this field is used in 
>> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses 
>> `icontains` lookup).
>> That is quite unfortunate for the big projects, as I have to come up 
>> with some generic solution to something that was not broken before this 
>> 

Re: modelform_factory and __module__ name

[Silvio]

That helps, thanks.

I don't think it's worth it either, because, ultimately, it'll still be 
"wrong". The right __module__ is wherever you called modelform_factory from.

The perils of meta programming...
On Monday, August 29, 2022 at 11:33:50 AM UTC+2 j.bre...@netzkolchose.de 
wrote:

> Looks to me like being carried forward from the very first metaclass 
> ``MediaDefiningClass``, which happens to be defined in 
> django.forms.widgets.
>
> Should be fixable by explicitly adding a __module__ notion to type().
>
> Not sure though if it is worth additional code just for the sake of 
> pretty __module__ alignment.
>

-- 
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/f92a5960-eb09-4bdc-9788-6e7fc51f56d1n%40googlegroups.com.

modelform_factory and __module__ name

[Silvio]

Hi all,

Not quite sure if this is the right forum, but it concerns Django itself 
and static analysis of it.

I'm working heavily on static analysis of the Django code base, including 
mypy and Django-stubs.

For the life of me, I cannot figure out why the class returned by 
modelform_factory has "django.forms.widgets" as its __module__. I can see 
it having "django.forms.models" or the like, but the former makes no sense.

It's not a huge issue, as ultimately dynamic classes will have localized 
module names but it's been bugging me for a while.

Give it a try in a plain Django installation: model passed to 
modelform_factory and inspect the module name.

Best,

Silvio

-- 
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/6db415e1-1abb-4f62-9658-3c57298555dfn%40googlegroups.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Silvio]

Since these are PotsgreSQL-specific fields that are being deprecated, might 
it make sense to provide a hint as to what the CreateCollation() call 
should be?

I'm looking around and it's not immediately obvious. The CreateCollation() 
examples in Django are for a German phone book, where in reality, I think 
99% of cases are going to be for case insensitive emails.

The deprecation notice in the patch currently shows an ellipsis.
On Thursday, July 28, 2022 at 7:03:10 AM UTC-4 Mariusz Felisiak wrote:

> https://code.djangoproject.com/ticket/33872
>

-- 
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/96c28e9f-5b63-4465-8622-1fb8a4921fe2n%40googlegroups.com.

Re: improvement for the front end

[Silvio]

Thanks! Yea I promised I was going to write docs one day. Better late than 
never!

On Wednesday, March 16, 2022 at 7:21:11 PM UTC-4 cheeri...@gmail.com wrote:

> Dude I saw this post on Reddit today! When I checked GitHub I saw I was 
> already following you and I was like wait what? And I remembered our 
> conversation.
>
> Great job  I read through the docs earlier. Very impressive. I dont work 
> with Python at the moment so I can’t use it but I’m going to follow this 
> project.
>
> Sent from my iPhone
>
> On Mar 16, 2022, at 7:11 PM, Silvio  wrote:
>
> Check out my recently launched project as well: 
> https://www.reactivated.io
>
>
> Zero-configuration Django and React. Basically, you use React as a 
> template engine for Django.
>
> On Wednesday, March 16, 2022 at 12:25:31 PM UTC-4 Adam Johnson wrote:
>
>> Hi
>>
>> I think you might enjoy reading up on htmx: https://htmx.org/ . This 
>> allows you to write html attributes that fetch extra HTML fragments from 
>> Django, no JavaScrip required. It's been quite popular at Django 
>> conferences recently. I maintain the small package django-htmx which has 
>> some tools and tips for using htmx with Django: 
>> https://django-htmx.readthedocs.io/en/latest/ .
>>
>> Thanks,
>>
>> Adam
>>
>> On Wed, Mar 16, 2022 at 2:08 PM Jans Green  wrote:
>>
>>> good day Djangueros!, this is a message for the most advanced in the 
>>> language, it is very tedious to work with django when you need your web to 
>>> be dynamic in the front end, having a lot of dependency on javascript, 
>>> that's why you use djano restframework to divide django as back end and 
>>> front end use react js or other, do you know that there is render? render 
>>> reads any .HTML file and displays it as such, because based on this we 
>>> create something that reads any js file, and inside the file looks for any 
>>> command that starts with (% some code %) and through this the django 
>>> backend and the javascripts frontend communicates directly without going 
>>> through the HTML, that is Django =><=Javascripts =>HTML would be something 
>>> like this variable = 12345 Render(variable, "javascripts.js"), the reason 
>>> for this is that I see a lot of consumption of resources using django as 
>>> absolutely backend and for front end other methods like reactjs, django has 
>>> a server and for the front end it needs another one and they communicate by 
>>> api rest. what do they say cheer up?
>>>
>>>
>>> Español==
>>>
>>> buen dia Djangueros!, este es un mensaje para los mas avanzados en el 
>>> lenguaje, es bien tedioso trabajar con django cuando necesita de que tu web 
>>> sea dinamica en el front end, teniendo mucha dependencia de javascript, por 
>>> ello usas djano restframework para dividir django como back end y front end 
>>> usan react js u other, ustedes saben que existe render? render lee 
>>> cualquier archivo .HTML y la mostra como tal, porque basado en esto creamos 
>>> algo que lea cualquier archivo js, ​​y dentro del archivo busque cualquier 
>>> comando que empieze con (% algun codigo %) y atravez de este el backend de 
>>> django y el frontend de javascripts se comunica directamente sin pasar por 
>>> el HTML, osea Django =><=Javascripts =>HTML seria algo asi variable = 12345 
>>> Render(variable, "javascripts.js"), la razon de esto es que veo mucho 
>>> consumo de recursos usando django como absolutamente backend y para front 
>>> end otro metodos como reactjs, django posee un servidor y para el front end 
>>> necesita otro y se comunican por api rest. que dicen se animan?
>>>
>>> -- 
>>> 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/bd18a9db-eb41-48a6-99db-470c9022e8d8n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/bd18a9db-eb41-48a6-99db-470c9022e8d8n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 

Re: improvement for the front end

[Silvio]

Check out my recently launched project as well: https://www.reactivated.io

Zero-configuration Django and React. Basically, you use React as a template 
engine for Django.

On Wednesday, March 16, 2022 at 12:25:31 PM UTC-4 Adam Johnson wrote:

> Hi
>
> I think you might enjoy reading up on htmx: https://htmx.org/ . This 
> allows you to write html attributes that fetch extra HTML fragments from 
> Django, no JavaScrip required. It's been quite popular at Django 
> conferences recently. I maintain the small package django-htmx which has 
> some tools and tips for using htmx with Django: 
> https://django-htmx.readthedocs.io/en/latest/ .
>
> Thanks,
>
> Adam
>
> On Wed, Mar 16, 2022 at 2:08 PM Jans Green  wrote:
>
>> good day Djangueros!, this is a message for the most advanced in the 
>> language, it is very tedious to work with django when you need your web to 
>> be dynamic in the front end, having a lot of dependency on javascript, 
>> that's why you use djano restframework to divide django as back end and 
>> front end use react js or other, do you know that there is render? render 
>> reads any .HTML file and displays it as such, because based on this we 
>> create something that reads any js file, and inside the file looks for any 
>> command that starts with (% some code %) and through this the django 
>> backend and the javascripts frontend communicates directly without going 
>> through the HTML, that is Django =><=Javascripts =>HTML would be something 
>> like this variable = 12345 Render(variable, "javascripts.js"), the reason 
>> for this is that I see a lot of consumption of resources using django as 
>> absolutely backend and for front end other methods like reactjs, django has 
>> a server and for the front end it needs another one and they communicate by 
>> api rest. what do they say cheer up?
>>
>>
>> Español==
>>
>> buen dia Djangueros!, este es un mensaje para los mas avanzados en el 
>> lenguaje, es bien tedioso trabajar con django cuando necesita de que tu web 
>> sea dinamica en el front end, teniendo mucha dependencia de javascript, por 
>> ello usas djano restframework para dividir django como back end y front end 
>> usan react js u other, ustedes saben que existe render? render lee 
>> cualquier archivo .HTML y la mostra como tal, porque basado en esto creamos 
>> algo que lea cualquier archivo js, ​​y dentro del archivo busque cualquier 
>> comando que empieze con (% algun codigo %) y atravez de este el backend de 
>> django y el frontend de javascripts se comunica directamente sin pasar por 
>> el HTML, osea Django =><=Javascripts =>HTML seria algo asi variable = 12345 
>> Render(variable, "javascripts.js"), la razon de esto es que veo mucho 
>> consumo de recursos usando django como absolutamente backend y para front 
>> end otro metodos como reactjs, django posee un servidor y para el front end 
>> necesita otro y se comunican por api rest. que dicen se animan?
>>
>> -- 
>> 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/bd18a9db-eb41-48a6-99db-470c9022e8d8n%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/5e1b1b03-253a-4543-bcef-0b406ae6686en%40googlegroups.com.

Documenting URL params filter behavior with ModelAdmin.lookup_allowed()

[Silvio]

Hi all,

I recently removed a filter from an admin change list view, but refreshed 
the page and to my surprise: the filter still worked!

I thought I stumbled upon a bug, but upon closer inspection, this is the 
correct behavior. That is, by default, the Django admin allows you to 
filter pretty much on any field in the model. Possibly even related fields 
too. The filters on the right are just UX conveniences.

I hold no strong opinion on whether this is a good idea or not. It's 
certainly convenient for craftier users. But I think we could do a better 
job documenting this. The *only* mention I could find on this is 
ModelAdmin.lookup_allowed 
here: 
https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.lookup_allowed

This sort of hints at the feature, and that you could turn it off by 
overriding etc. But there's no other mention of it on the page.

Should we make it clearer?

Thank you all. Been using Django for 12 years and never been happier.

Best,

Silvio

-- 
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/5065d98e-1944-4336-9206-00b602e27a4an%40googlegroups.com.

Re: Redundant migration code

[Silvio J. Gutierrez]

That's what I originally thought. But if I look at the code, it's entirely
self contained to the existing model. There's no variable in scope that
lets it reach outside the app/model in question.

And thanks for writing the migration feature! I remember when it first came
out. Easily one of my favorite Django batteries.

On Sat, Sep 19, 2020 at 5:40 PM Andrew Godwin  wrote:

> I suspect the reason for this might be to undo circular references of
> ForeignKeys between apps - in this situation, you have to first have a
> migration that removes one FK, then in the other app remove the model, then
> in the first app remove the model.
>
> I can't quite remember though - but that would be my suspicion as to why
> this would be structured this way in my original code. As you say, the
> optimiser has improved in the years since, but I don't think you can
> optimise away the circular reference problem?
>
> Andrew
>
> On Sat, Sep 19, 2020, at 3:20 PM, Silvio J. Gutierrez wrote:
>
> 3 tests fail when I comment out the code, however, I suspect it's because
> of this:
>
> test_autodetector.py#586
>
> It's directly calling _detect_changes before piping it to the optimizer.
> So rightly so, it expects more operations than post optimization.
>
> I could be totally wrong though.
>
> Basically, with code (and what the unit test asserts):
>
> ['RemoveField', 'RemoveField', 'DeleteModel', 'DeleteModel']
>
> Without code:
>
> ['DeleteModel', 'DeleteModel']
>
> With code but after optimizer:
>
> ['DeleteModel', 'DeleteModel']
>
> But the unit test is looking at pre-optimizer output. I think.
>
> On Sat, Sep 19, 2020 at 2:23 PM Adam Johnson  wrote:
>
> Did you try deleting this code and seeing if any test failed?
>
> On Sat, 19 Sep 2020 at 17:54, Silvio  wrote:
>
> I've been digging around the 3.1 migration code just out of curiosity, and
> I stumbled upon this in autodetector.py#772:
>
> for name in sorted(related_fields):
> self.add_operation(
> app_label,
> operations.RemoveField(
> model_name=model_name,
> name=name,
> )
> )
>
> It appears that all related fields for a model are removed before removing
> a model. This is great, *except*, optimizer.py will always strip these
> migrations out.
>
> That is: the RemoveField operations for related fields are always adjacent
> to the DeleteModel operation, so I cannot think of any case where
> optimizer.py will *not* strip these out.
>
> Am I missing something, or is this code that no longer contributes value?
> Perhaps the optimizer has gotten better since?
>
> Best,
>
> Silvio
>
>
> --
> 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/46e53585-64f3-4e88-87a7-2cab7722aefan%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/46e53585-64f3-4e88-87a7-2cab7722aefan%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>
> --
> Adam
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/fwwSmD3zBpQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y9WD-8VR2hC93tu7BtgWrEr0j4nfOx9HSLbi0mm%3D50A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y9WD-8VR2hC93tu7BtgWrEr0j4nfOx9HSLbi0mm%3D50A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANfEt_abmcbUp_QdUJSebRm9od5dKjtz7DkFgOXVBL5O8yisfg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CANfEt_abmcbUp_QdUJSebRm9od5dKjtz7DkFgOXVBL5O8yisfg%40mail.gmail.com?utm_med

Re: Redundant migration code

[Silvio J. Gutierrez]

3 tests fail when I comment out the code, however, I suspect it's because
of this:

test_autodetector.py#586

It's directly calling _detect_changes before piping it to the optimizer. So
rightly so, it expects more operations than post optimization.

I could be totally wrong though.

Basically, with code (and what the unit test asserts):

['RemoveField', 'RemoveField', 'DeleteModel', 'DeleteModel']

Without code:

['DeleteModel', 'DeleteModel']

With code but after optimizer:

['DeleteModel', 'DeleteModel']

But the unit test is looking at pre-optimizer output. I think.

On Sat, Sep 19, 2020 at 2:23 PM Adam Johnson  wrote:

> Did you try deleting this code and seeing if any test failed?
>
> On Sat, 19 Sep 2020 at 17:54, Silvio  wrote:
>
>> I've been digging around the 3.1 migration code just out of curiosity,
>> and I stumbled upon this in autodetector.py#772:
>>
>> for name in sorted(related_fields):
>> self.add_operation(
>> app_label,
>> operations.RemoveField(
>> model_name=model_name,
>> name=name,
>> )
>> )
>>
>> It appears that all related fields for a model are removed before
>> removing a model. This is great, *except*, optimizer.py will always strip
>> these migrations out.
>>
>> That is: the RemoveField operations for related fields are always
>> adjacent to the DeleteModel operation, so I cannot think of any case where
>> optimizer.py will *not* strip these out.
>>
>> Am I missing something, or is this code that no longer contributes value?
>> Perhaps the optimizer has gotten better since?
>>
>> Best,
>>
>> Silvio
>>
>> --
>> 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/46e53585-64f3-4e88-87a7-2cab7722aefan%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/46e53585-64f3-4e88-87a7-2cab7722aefan%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/fwwSmD3zBpQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y9WD-8VR2hC93tu7BtgWrEr0j4nfOx9HSLbi0mm%3D50A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3Y9WD-8VR2hC93tu7BtgWrEr0j4nfOx9HSLbi0mm%3D50A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANfEt_abmcbUp_QdUJSebRm9od5dKjtz7DkFgOXVBL5O8yisfg%40mail.gmail.com.

Redundant migration code

[Silvio]

I've been digging around the 3.1 migration code just out of curiosity, and 
I stumbled upon this in autodetector.py#772:

for name in sorted(related_fields):
self.add_operation(
app_label,
operations.RemoveField(
model_name=model_name,
name=name,
)
)

It appears that all related fields for a model are removed before removing 
a model. This is great, *except*, optimizer.py will always strip these 
migrations out.

That is: the RemoveField operations for related fields are always adjacent 
to the DeleteModel operation, so I cannot think of any case where 
optimizer.py will *not* strip these out.

Am I missing something, or is this code that no longer contributes value? 
Perhaps the optimizer has gotten better since?

Best,

Silvio

-- 
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/46e53585-64f3-4e88-87a7-2cab7722aefan%40googlegroups.com.

Re: Proposal: relationships based on arbitrary predicates

[Silvio]

Alex,

This is a very useful pattern, that like many others, I've also implemented 
in an ad-hoc fashion using a ton of undocumented internal APIs. So I fully 
agree standardizing it would be great. Something similar is:

https://groups.google.com/forum/#!topic/django-developers/ADSuUUuZp3Q

Essentially, I've ended up with the need for:

ComputedField

and

ComputedRelationship

where both have all of the niceties that regular fields and foreign 
relationships have.

So I'd love to see this in Django.

-
Silvio


On Sunday, September 2, 2018 at 10:55:58 PM UTC-4, Alex Hill wrote:
>
> Hi Simon,
>
> Thanks for looking at this and for providing some context - I had looked 
> at FilteredRelation but I hadn't seen reverse-unique. It makes me more 
> confident that this is a good direction to take. I've reimplemented 
> ReverseUnique using Relationship [0] and the tests pass, with the only code 
> carried over that for discovery of the FK link.
>
> > I'm not totally sold on the API but having an analog of what 
> ForeignObject is to ForeignKey for ManyToManyField would definitely be 
> useful.
>
> I'm not tied to the API, but I think passing a Q as a predicate makes 
> sense especially given that it's what both FilteredRelation and 
> ReverseUnique do. The core of the idea is that we can express a 
> relationship as a combination of predicate and arity. In practise I don't 
> think this would be used all that much by users directly - more by 
> third-party apps like mptt, and perhaps Django internally.
>
> > From what I can see in relativity.fields[0] most of the additional logic 
> revolves around the extra filtering capabilites through Restriction.
>
> Yeah that's what it boils down to. We return no columns to join against, 
> and return a compilable Restriction from get_extra_restriction to provide 
> all the ON conditions. The rest of it is making the descriptors, rels, 
> prefetch, etc work.
>
> > Do you have an idea of what the fields.related inheritance chain would 
> look like if it was part of core?
>
> The least intrusive, and probably a good starting point, would be to 
> introduce Relationship alongside the other relation fields as a standalone 
> feature, modifying the ORM to allow the implementation to be less hacky. It 
> would remain a subclass of ForeignObject (or perhaps RelatedField - I'll 
> give that a try).
>
> In the future there's potential for a nice refactor of the ORM to 
> generalise join conditions from key-equality to arbitrary predicates of 
> which key equality is just one case, at which point Relationship could sit 
> comfortably as a base class of all the other relations. The assumption that 
> join==key-equality is pervasive and I think that's an unnecessarily large 
> chunk of work to take on at this point - it would be better to get the 
> feature in, then have a release cycle or so to think about the best way to 
> approach that problem and if we even want to.
>
> I would be happy to write up a DEP expanding on an implementation plan and 
> potential future work.
>
> Thanks,
> Alex
>
> [0] 
> https://github.com/AlexHill/django-reverse-unique/blob/624c8b19406a40b8e1a2c969c23a6b45bed5a896/reverse_unique/fields.py
>
>
>
>
>
>
> On Fri, 31 Aug 2018 at 12:12 am, charettes  > wrote:
>
>> Hello Alex!
>>
>> Thanks for your work on this project, this is definitely something that I 
>> believe would be useful in Django's core based on the number of times I 
>> implemented a filtered queryset getter on Models.
>>
>> I'm not totally sold on the API but having an analog of what 
>> ForeignObject is to ForeignKey for ManyToManyField would definitely be 
>> useful.
>>
>> From what I can see in relativity.fields[0] most of the additional logic 
>> revolves around the extra filtering capabilites through Restriction.
>>
>> Do you have an idea of what the fields.related inheritance chain would 
>> look like if it was part of core? I feel like having 
>> Relation(RelatedField), ForeignObject(Relation), ManyToManyField(Relation) 
>> and adding the filtering logic to Relation could work but I'd be interested 
>> to hear what you think here. FWIW Anssi implemented something similar[1] 
>> for reverse unique relationship before FilteredRelation() was introduced.
>>
>> In a sense Relation would be form of virtual field like ForeignObject 
>> since it's not in charge of any database field handling.
>>
>> Simon
>>
>> [0] 
>> https://github.com/AlexHill/django-relativity/blob/3802608c64e86c62ab6268efc37a3f5ca8539221/relativity/fields.py
>> [1] https://github.com/akaariai/django-reverse-unique
>>
>>
>>
>> Le jeudi 

Re: models.CalculatedField feature

[Silvio]

I implemented this feature by having a default manager that overrides 
get_queryset. it loops over any calculated field declared on the model and 
annotates that model. Always.

The main issue I ran into is that these fields were not query-able when 
used for related lookups.

So:

Customer.objects.filter(is_adult=True) worked fine.

But Orders.objects.filter(customer__is_adult=True) did not, because these 
related queries did *not* go through the objects.get_queryset we know and 
love.

So if this addition could handle these cases, it'd be great.

Otherwise, it can already be done by just providing a 
"CalculatedFieldManager" and assigning that to your model.

On Monday, November 20, 2017 at 10:31:31 PM UTC-5, ilya.ka...@jetbrains.com 
wrote:
>
> Thank you all.
>
> I've created a feature request https://code.djangoproject.com/ticket/28822 
> and 
> will try to implement in my Django fork next week. I am not Django source 
> code guru, so any help is welcome:)
>

-- 
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/ef8fc778-a4b4-4d39-a07d-fb329a19c4ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration "rebase", or just an "undo" that works with conflicts

[Silvio]

I've had this situation come up too. It would indeed be very useful.

Django South had something vaguely related:

http://south.readthedocs.org/en/latest/tutorial/part3.html

However, the command did not make it over to built-in migrations.

On Monday, November 30, 2015 at 8:44:37 AM UTC-5, Shai Berger wrote:
>
> Hello, 
>
> Part of my work lately was to help bring a large, complex project from 
> Django 
> 1.7 to 1.8. This effort was being done in parallel to continued 
> development of 
> the project, in a separate branch. To make things more fun, the project 
> uses 
> UUID fields for PKs in many models; on 1.7, this was done with 
> django-uuidfield, 
> but of course, with 1.8 we changed this to models.UUIDField. As a result, 
> many 
> apps have migrations for moving to 1.8 (there are also a few more for 
> EmailField's etc). 
>
> I found myself, several times, getting new migrations in an app where I've 
> already added the 1.8-related migrations. When this happened, what I'd 
> like to 
> do is "rebase" the migration -- undo it, delete it, and recreate it on top 
> of 
> the newly-added migrations. 
>
> However, doing that turned out hard. Not only is there no single operation 
> for 
> it, I couldn't even do the parts easily -- I could neither undo the 
> migration 
> nor even fake it out, because the migration folder was in a "merge 
> conflict" 
> state (more than one final migration). 
>
> A rebasemigration command would be wonderful. But the building block for 
> it -- 
> the ability to undo a single migration, even when a conflicting one has 
> been 
> added to the tree, seems both more essential and easier to do. 
>
> Thoughts? 
>
> Thanks, 
> Shai. 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77b63ad8-a16b-4ba3-bf3a-3ae5885f85e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: minify static files (css and js)

[Silvio]

I feel inclined to mention the tool I built:
https://www.sgawebsites.com/projects/django-aggregator/ . Very easy to
use, and easy to deploy.

-
Silvio

On Aug 9, 1:44 am, Alexander Schepanovski <suor@gmail.com> wrote:
> I prefer webassets. You may also look into.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Old Django Versions

[Silvio]

Hi Spencer,

This sounds like a question for the Django Users group. The Django
Developers group is for matters relating to the development of the
framework itself. You can find the right group here:
http://groups.google.com/group/django-users

To answer your question though: thanks to the hard work of many
people, Django 1.2 and 1.3 added a ton of useful features. It'd be a
shame if you learned about a feature only to find out that you can't
use it because you're running 1.1. For example, class-based generic
views alone (added in 1.3) improved the general quality of my life by
47%.

So I suggest you work with 1.3 if at all possible.

Silvio

On Jun 27, 11:54 am, spencer cole <spencer.c...@gmail.com> wrote:
> Howdy. I'm a new developer for Django. My work is starting work using
> Django 1.3, and I find I really like it as far as I've used it so far.
> My web hosting service, Site5, supports Django, but it's an old
> version(1.1). Is there going to be any issue with what I learn and use
> in Django 1.3 when I try to make my website on my host's servers? Or
> should I install a local version? Also, Site5 runs Python 2.4, should
> I run a local version of 2.7 as well?
>
> Thanks for nay help!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Transaction Documentation Clarification

[Silvio]

Hello all,

I recently switched to using transactions, and found Django's offering
to be excellent. I was just wondering if we could clarify a small bit
of the documentation - or whether I simply misunderstood it.

When using @transaction.commit_manually, one needs to ROLLBACK or
COMMIT, otherwise the transaction handler will raise the
TransactionManagementError error. That much is clear. But does this
mean the *entire* view needs to be wrapped in a massive "try/except/
else" block? I ask because, if any kind of exception occurs after the
transaction has started, I'll be presented with
TransactionManagementError rather than the exception. This makes
debugging a bit hard.

So basically, the following code:

@transaction.commit_manually
def some_view(request):
SomeModel.objects.all() # To trigger the start of a transaction.
some_function_that_could_raise_an_exception()
transaction.commit()

will always show the TransactionManagementError if an exception occurs
unless we do:

@transaction.commit_manually
def some_view(request):
try:
SomeModel.objects.all() # To trigger the start of a
transaction.
some_function_that_could_raise_an_exception()
# Rest of view body. This could be tons of lines.
except Exception as e:
transaction.rollback()
raise e
else:
transaction.commit()

return HttpResponse("Made it through the view with no errors")


The documentation *does* show a try/except/else block[1], but I found
it a bit unclear that any and all exceptions need to be caught, the
transaction rolled back, and the exception raised again.

Let me know your thoughts. As always, thanks a lot for the hard work.
Just tried class-based views in 1.3, and they're awesome.

Silvio

[1] 
http://docs.djangoproject.com/en/dev/topics/db/transactions/#django.db.transaction.commit_manually

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#13717: What to do next?

[Silvio]

Hey guys,

I opened ticket #13717, and it seems to be reproducible by other
people. Someone contributed a patch, but the ticket is "stuck" because
it needs tests.

I would really like to see this fixed by 1.3, so I'd be more than
happy to write these and submit them. But I'm not sure in which file
the tests belong. I'd appreciate any pointers.

Thanks,

Silvio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Introducing a CACHE_MIDDLEWARE_KEY_PREFIX-like setting for all cacheing operations (#12831)

[Silvio]

Great idea, I'd like to see this implemented too.

Running a memcached instance for small sites seems like overkill.

I'm willing to help write whatever code is necessary.

Silvio

On May 24, 4:21 am, Julien Phalip <jpha...@gmail.com> wrote:
> Hi,
>
> Several people have expressed interest in ticket #12831, which has
> also been marked as DDN. So I thought the next step would be to bring
> it up on this list - let me know if that's not the right thing to do.
>
> Basically, I think that it would make sense and that it would be very
> useful if a new setting was introduced to allow the systematic
> addition of a prefix to avoid key collisions across multiple site
> instances, that is for all cacheing operations, not just for per-site
> cacheing (which is currently possible with the
> CACHE_MIDDLEWARE_KEY_PREFIX setting).
>
> What do you guys think about this? Does this ticket have a chance to
> be accepted or is it fundamentally a bad idea?
>
> Many thanks.
>
> Kind regards,
>
> Julien
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Silvio]

Owen,

The file is only created once, so the compression only happens once.
Only when any of the files being aggregated is changed does the file
get recreated.

In other words, the process is automatic, but it has no performance
penalty.

Silvio

On Apr 30, 10:27 am, Owen Nelson <onel...@gmail.com> wrote:
> In this case you're compressing at runtime... or am I missing something?
>
> I think I'm just going to burrow for a little while and prototype some
> helpers.  I've got a project coming up shortly with some room for R on
> this front, so hopefully I'll be able to put them into production for a
> while before I bug anyone again.
> I'll be back (at some point) when I've got something I think will
> benefit the community.
>
> Thanks for all the interest in the topic though - I think that proves we
> are all hungering for *something* even if we're not exactly sure as to
> what it is.
>
> Silvio wrote:
> > Consider taking a look at an app I 
> > wrote,http://www.sgawebsites.com/projects/django-aggregator/.
>
> > It aggregates all JS and CSS files using a very simple syntax. It can
> > also pipe the content through YUI Compressor before saving the
> > aggregate.
> > My aim was to make it extremely easy to use. It's not an asset manager
> > though; I've yet to see or come up with a great solution.
>
> > Regards,
>
> > Silvio
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Silvio]

Consider taking a look at an app I wrote, 
http://www.sgawebsites.com/projects/django-aggregator/.

It aggregates all JS and CSS files using a very simple syntax. It can
also pipe the content through YUI Compressor before saving the
aggregate.
My aim was to make it extremely easy to use. It's not an asset manager
though; I've yet to see or come up with a great solution.

Regards,

Silvio

On Apr 23, 10:51 am, Owen Nelson <onel...@gmail.com> wrote:
> Kevin Howerton wrote:
> > The widget and admin media system needs to be re-evaluated IMO
> > none of these solutions are going to address the flaws you are
> > referring to.
>
> "Flaws", sounds a bit harsh :P  Let's alias that as "room for improvement".
> I'd agree that wrangling hashes and compressing assets at run-time is
> undesirable, and that a management command is preferable.
> There's a bit of conflict between what I crave, and the
> compress-everything-ahead-of-time tactic though.  Actually... I take
> that back - following Gabriel's train of though, we could probably have
> it both ways.
>
> Since my goals are somewhat smaller (in some ways), I've started
> thinking about ways to implement what I want (some kind of "global"
> stack of client-side resources) that won't require sticking my fingers
> in the django source.  At least not yet.
> Here's kind of what I'm thinking about:http://dpaste.org/Pjk5/
> (Sorry, the naming is all a bit clunky - that was just off the top of my
> head)
>
> Extending something simple like that with some template tags, and
> stringing it all together with some middleware.
> This would give us a way to pool scripts together under one framework
> instance, also allowing us to dynamically add (from views and templates)
> them to the framework container throughout the life cycle of a request
> and response.
> I think I might be able to run some tests in a custom app - then start
> experimenting with the admin site.
>
> Once I've got all that setup, it should be a snap to add
> compression/concatenation somewhere along the  pipeline, either at
> runtime or via a management command.
>
> Obviously, this is all very jQuery specific (where most of my javascript
> experience lies).  I'd love to hear from someone on team dojo,
> prototype, yui, or extjs to learn about what doesn't fit with this model.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.