Re: Custom collation support

[charettes]

> I like this idea, but I think we'd still want to offer the option of 
using strings, since most projects run only against one database backend. 
Compilable objects would be more effort so perhaps best to leave for now, 
at least until the PR is much more developed.

Makes sense, lets focus on only adding support for db_collation: str for 
now then.

Simon

Le lundi 20 juillet 2020 à 05:36:52 UTC-4, Adam Johnson a écrit :

> I like where it's heading but I wonder if it'd be more appropriate to 
>> start by supporting a _compilable_ object instead of a string at first.
>>
>
> I like this idea, but I think we'd still want to offer the option of using 
> strings, since most projects run only against one database backend. 
> Compilable objects would be more effort so perhaps best to leave for now, 
> at least until the PR is much more developed.
>  
>
>> Another question I had is whether or not the option should be named 
>> db_collation like we do for db_index, db_column, and db_tablespace since 
>> it's a database only option. It feels like using the db_ prefix would make 
>> most sense here particularly if we only allow string collations to be 
>> specified at first.
>
>
> +1 to this.
>
> The contrib.postgres migration operations to create and delete collation 
>> could be useful but it increases the scope of your proposed changed and 
>> will slow down its review and affect its mid-term mergeability.
>>
>
> Yes, it is probably best to extract the operations to another ticket/PR.
>
> On Mon, 20 Jul 2020 at 03:48, charettes  wrote:
>
>> Thanks for your work so far Tom!
>>
>> > There is perhaps some scope in the future to make this take a callable 
>> that can figure out the collation per-database. This would be useful for 
>> getting case-insensitive lookups working across all backends, for example. 
>> But I want to keep that out of the scope because it's some extra work and 
>> I'm not sure on the implementation.
>>
>> I like where it's heading but I wonder if it'd be more appropriate to 
>> start by supporting a _compilable_ object instead of a string at first. By 
>> compilable I mean an object that has an as_sql(connection) method to allow 
>> per-backend logic to be applied. For example, one might define 
>> Collation(casesensitive=False) compilable that translates to `NOCASE` on 
>> SQLite, and equivalent on other databases. I'm just throwing that out 
>> there, maybe there's no sane of making that work in a database agnostic way 
>> without adding much and we should start by only allowing a string as you've 
>> suggested.
>>
>> Another question I had is whether or not the option should be named 
>> db_collation like we do for db_index, db_column, and db_tablespace since 
>> it's a database only option. It feels like using the db_ prefix would make 
>> most sense here particularly if we only allow string collations to be 
>> specified at first.
>>
>> > I'm new to the schema migration code and I don't want to take on too 
>> much at once.
>>
>> I'd focus your PR on solely adding the option to specify a column 
>> collation in this case. The contrib.postgres migration operations to create 
>> and delete collation could be useful but it increases the scope of your 
>> proposed changed and will slow down its review and affect its mid-term 
>> mergeability. Given it can be achieved using RunSQL operations only the 
>> Field.db_collation extension point is 
>>
>> +1 to what Aymeric said regarding field alterations. Adding or removing a 
>> collation from a CharField/TextField should generate an AlterField 
>> operation that adds or remove the COLLATE clause from the column 
>> definition. Looks like you already implemented the schema editor bits of it 
>> but it should also be tested which will possibly involve writing some 
>> database introspection bit to assert the operation was correctly performed.
>>
>> > In MySQL (at least) columns also have a charset property that goes 
>> hand-in-hand with which collations are available. I know it expands the 
>> scope, but I think it would be good to get that in here. Perhaps it could 
>> be a follow-up ticket though.
>>
>> > The code here works across all backends, I'm not sure how it'd work for 
>> the charset. Would we add a new kwarg to Char/TextField just for MySQL? I 
>> think there are a few more questions to answer before tackling it, but I 
>> agree that if we add collations, we should add charsets for MySQL too, as 
>> they're so closely related.
>>
>> I guess it should be handled in a different ticket and discussed before 
>> hand. Not sure how common it is to want to define a per-column charset and 
>> since it would be already indirectly achievable by defining a collation 
>> (MySQL charset defaults to the charset of the collation when only the 
>> latter is specified, not sure about Oracle) it feels like the addition of a 
>> top level CharField/TextField option to allow specifying a charset that 
>> uses its default collation is not warranted.
>>

Re: Auto-installation of 3rd party packges

[Kacper Szmigiel]

Hey!

Back in the day, like 2017 or something, I was using Ansible tool for such
things. As far as I know (unfortunately I don't work on Django projects on
daily basis today) now it's pretty standard to set up a project once, and
later just use Docker for a unified dev environment.

I've starred your project, I keep my fingers crossed for its success and
development.

Best wishes,
Kacper Szmigiel

pon., 20 lip 2020 o 11:58 Dave R  napisał(a):

> Hello all,
> I recently got done with v1 of this project:
> https://github.com/pandichef/indjections
>
> It's an installation utility for 3rd party Django packages.
>
> But then I started thinking about the issue more generally...
>
> I'm writing here because I'm kind of amazed why Django package
> installation often requires so many steps e.g., various configurations in
> settings.py,  some kind URL support in urls.py, add some stuff to
> base.html.  See django-hijack
> and
> django-allauth
>  as
> examples.
>
> It's all reminiscent of Python package distribution before distutils.
>
> I think some kind of automated way to install packages should be part of
> the Django itself.  Just a thought...
>
> My solution is to insert bits of code in the "right" places.   I'm curious
> how others have solved this problem.
>
> Thanks,
> Dave
>
> --
> 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/7c10b710-7abf-42e6-b41d-3e856aad288an%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/CAFfZ%2Bb6BN8TkvUwfGdmuYoSib%3DOhWcZwu4Fsun9JoUHRjJMbzQ%40mail.gmail.com.

child pages url update when changing parent's slug (only when logged)

[Beniamino Nobile]

Hello I've a problem in my site menu. The django cms version is 3.7.2 I've 
four languages (en, it, de, fr)

When an anonymous user use the site the menu is correct. When I'm logged 
from the admin panel i see some strange behaviors: when I've a second level 
page the url is composed with the parent slug in the wrong language (and if 
I do any change to the slug an publish it i still see the old slug)


This happen each time i've to chande the parent's slug.

If i also publish again the child pages, then the problems seem to be solved



Here's the code for the menu.html

{% load menu_tags %}
{% for child in children %}
{{ child.get_menu_title }}
{% if child.children %}

{% show_menu from_level to_level extra_inactive extra_active template 
"" "" child %}

{% endif %}{% endfor %}

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/97537f5a-8499-4f43-92b5-10a27c82e077o%40googlegroups.com.

Auto-installation of 3rd party packges

[Dave R]

Hello all,
I recently got done with v1 of this project:
https://github.com/pandichef/indjections

It's an installation utility for 3rd party Django packages.

But then I started thinking about the issue more generally...

I'm writing here because I'm kind of amazed why Django package installation 
often requires so many steps e.g., various configurations in settings.py,  
some kind URL support in urls.py, add some stuff to base.html.  See 
django-hijack 
and django-allauth 
 as 
examples.

It's all reminiscent of Python package distribution before distutils.

I think some kind of automated way to install packages should be part of 
the Django itself.  Just a thought...

My solution is to insert bits of code in the "right" places.   I'm curious 
how others have solved this problem.

Thanks,
Dave

-- 
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/7c10b710-7abf-42e6-b41d-3e856aad288an%40googlegroups.com.

Re: Custom collation support

[Adam Johnson]

>
> I like where it's heading but I wonder if it'd be more appropriate to
> start by supporting a _compilable_ object instead of a string at first.
>

I like this idea, but I think we'd still want to offer the option of using
strings, since most projects run only against one database backend.
Compilable objects would be more effort so perhaps best to leave for now,
at least until the PR is much more developed.


> Another question I had is whether or not the option should be named
> db_collation like we do for db_index, db_column, and db_tablespace since
> it's a database only option. It feels like using the db_ prefix would make
> most sense here particularly if we only allow string collations to be
> specified at first.


+1 to this.

The contrib.postgres migration operations to create and delete collation
> could be useful but it increases the scope of your proposed changed and
> will slow down its review and affect its mid-term mergeability.
>

Yes, it is probably best to extract the operations to another ticket/PR.

On Mon, 20 Jul 2020 at 03:48, charettes  wrote:

> Thanks for your work so far Tom!
>
> > There is perhaps some scope in the future to make this take a callable
> that can figure out the collation per-database. This would be useful for
> getting case-insensitive lookups working across all backends, for example.
> But I want to keep that out of the scope because it's some extra work and
> I'm not sure on the implementation.
>
> I like where it's heading but I wonder if it'd be more appropriate to
> start by supporting a _compilable_ object instead of a string at first. By
> compilable I mean an object that has an as_sql(connection) method to allow
> per-backend logic to be applied. For example, one might define
> Collation(casesensitive=False) compilable that translates to `NOCASE` on
> SQLite, and equivalent on other databases. I'm just throwing that out
> there, maybe there's no sane of making that work in a database agnostic way
> without adding much and we should start by only allowing a string as you've
> suggested.
>
> Another question I had is whether or not the option should be named
> db_collation like we do for db_index, db_column, and db_tablespace since
> it's a database only option. It feels like using the db_ prefix would make
> most sense here particularly if we only allow string collations to be
> specified at first.
>
> > I'm new to the schema migration code and I don't want to take on too
> much at once.
>
> I'd focus your PR on solely adding the option to specify a column
> collation in this case. The contrib.postgres migration operations to create
> and delete collation could be useful but it increases the scope of your
> proposed changed and will slow down its review and affect its mid-term
> mergeability. Given it can be achieved using RunSQL operations only the
> Field.db_collation extension point is
>
> +1 to what Aymeric said regarding field alterations. Adding or removing a
> collation from a CharField/TextField should generate an AlterField
> operation that adds or remove the COLLATE clause from the column
> definition. Looks like you already implemented the schema editor bits of it
> but it should also be tested which will possibly involve writing some
> database introspection bit to assert the operation was correctly performed.
>
> > In MySQL (at least) columns also have a charset property that goes
> hand-in-hand with which collations are available. I know it expands the
> scope, but I think it would be good to get that in here. Perhaps it could
> be a follow-up ticket though.
>
> > The code here works across all backends, I'm not sure how it'd work for
> the charset. Would we add a new kwarg to Char/TextField just for MySQL? I
> think there are a few more questions to answer before tackling it, but I
> agree that if we add collations, we should add charsets for MySQL too, as
> they're so closely related.
>
> I guess it should be handled in a different ticket and discussed before
> hand. Not sure how common it is to want to define a per-column charset and
> since it would be already indirectly achievable by defining a collation
> (MySQL charset defaults to the charset of the collation when only the
> latter is specified, not sure about Oracle) it feels like the addition of a
> top level CharField/TextField option to allow specifying a charset that
> uses its default collation is not warranted.
>
> Simon
> Le dimanche 19 juillet 2020 à 09:57:58 UTC-4, t...@carrick.eu a écrit :
>
>> Thanks for the feedback.
>>
>> Aymeric, yes, I left out modification until I knew there was some
>> interest as that code seemed more impenetrable to me than the field
>> addition. I've added this now, does it seem like the right approach? I've
>> tested it on everything but Oracle and it seems to work as I'd expect. If
>> it generally looks good (and when/if the ticket
>>  is accepted) I'll write up
>> tests and docs... I'm not sure how 

Re: Should the docs suggest namespace packages?

[Florian Apolloner]

There are also various issues in python itself like 
https://bugs.python.org/issue23882 -- so I strongly recommend against 
namespace packages unless you actually need them.

On Monday, July 20, 2020 at 1:14:41 AM UTC+2 re...@fleschenberg.net wrote:

> Hi,
>
> On 7/19/20 10:25 PM, Tim Graham wrote:
> > Another commenter remarked, "We had a similar issue with test discovery.
> > One of our developers read an article that __init__.py files are not
> > required on Python3 and started removing them. Everything seemingly
> > worked but some tests were not discovered and did not run in CI (which
> > made it difficult to spot). I think Django should not required them if
> > technically possible or at least it should be made clear in the
> > documentation (sorry if I overlooked it)."
> > 
> > Supporting namespace packages without a real use case seems contrary to
> > the consensus in this thread (which I see as not promoting implicit
> > namespace packages). Based on that consensus, my inclination wouldn't be
> > to try to make Django work with as few __init__.py files as possible.
> > What do you think?
>
> I agree. The situation of "One of our developers read an article that
> __init__.py files are not required on Python3" is exactly the one we
> should act against, as far as we can. This is a common misunderstanding
> that we should try to clear up, not promote.
>
> The person you quoted gives an example of why this is not purely
> academical. Maybe it's debatable whether Python should behave
> differently, but that's not something that Django can fix.
>
> I am in favour of failing early and loudly here. IMHO Django should
> ignore migration packages without an __init__.py file, maybe with a
> warning, or maybe even with an error.
>
> -- 
> René Fleschenberg
>
>

-- 
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/c59be0e9-3773-4421-895e-c66d31f220a3n%40googlegroups.com.

Re: Fellow Reports - July 2020

[Mariusz Felisiak]

Week ending July 19, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31782 - Missing statements while 
creating [appName] on templates (invalid)
https://code.djangoproject.com/ticket/31781 - Not Found The requested 
resource was not found on this server (invalid)
https://code.djangoproject.com/ticket/31780 - Include the Python traceback 
in the debug-page footer as a HTML comment (wontfix)
https://code.djangoproject.com/ticket/31778 - Pass exception to 
ERROR_PAGE_TEMPLATE after catching TemplateDoesNotExist. (wontfix)
https://code.djangoproject.com/ticket/31779 - Executing complex JSONField 
queries crashes on MariaDB < 10.2.16 (invalid)
https://code.djangoproject.com/ticket/31784 - Emails name over 75 
characters are incompatible with the latest versions of python. (invalid)
https://code.djangoproject.com/ticket/31788 - Models migration with change 
field foreign to many and deleting unique together. (accepted)
https://code.djangoproject.com/ticket/31787 - dumpdata/loaddata BinaryField 
base64 decoding fails. (needsinfo)
https://code.djangoproject.com/ticket/31790 - HttpResponse.delete_cookie() 
should preserve cookie's samesite. (accepted)
https://code.djangoproject.com/ticket/31794 - NotImplementedError: 
subclasses of BaseCache must provide a touch() method (worksforme)
https://code.djangoproject.com/ticket/31795 - Allow overriding regional 
subtags convertion to lowercase (wontfix)
https://code.djangoproject.com/ticket/16893 - negation of Q object returns 
the same thing (wontfix)
https://code.djangoproject.com/ticket/31796 - DetailView Instance running 
twice for single rendering (invalid)
https://code.djangoproject.com/ticket/31797 - MariaDB 10.4 SchemaTests 
failures (accepted)
https://code.djangoproject.com/ticket/31798 - Let EmailField automatically 
transform value to lower case (duplicate)
https://code.djangoproject.com/ticket/31800 - Oracle InspectDB tests fail 
on Windows (duplicate)
https://code.djangoproject.com/ticket/31801 - Oracle schema tests error out 
on Windows (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/13176 - Fixed #31674 -- Made 
technical 500 debug page respect __suppress_context__.
https://github.com/django/django/pull/13178 - Fixed #31770 -- Allowed 
select_for_update(of) on MySQL 8.0.1+.
https://github.com/django/django/pull/12944 - Fixed #30457 -- Added 
TestCase.captureOnCommitCallbacks().
https://github.com/django/django/pull/13171 - Fixed #21528 -- Added note 
about filtering form field's queryset based on instance to admin docs.
https://github.com/django/django/pull/13155 - Added Igbo language.
https://github.com/django/django/pull/11359 - Fixed #30446 -- Resolved 
Value.output_field for stdlib types.
https://github.com/django/django/pull/13145 - Fixed #31623 -- Allowed 
specifying number of adjacent time units in timesince()/timeuntil().
https://github.com/django/django/pull/13193 - Refs #31502 -- Made minor 
edits to Model._state docs.
https://github.com/django/django/pull/13180 - Fixed #31731 -- Removed 
unreachable code for resetting sequences of auto-created m2m tables in 
sequence_reset_sql().

*Authored:*
https://github.com/django/django/pull/13195 - Fixed #31790 -- Fixed setting 
SameSite and Secure cookies flags in HttpResponse.delete_cookie().
https://github.com/django/django/pull/13197 - Stopped adapting DecimalField 
values to strings on Oracle.
https://github.com/django/django/pull/13204 - Fixed #17653 -- Allowed using 
zero as AutoFields value on MySQL if NO_AUTO_VALUE_ON_ZERO SQL mode is 
enabled.

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/dcd10d7f-3c41-423e-9728-da30d51b8d8do%40googlegroups.com.

Django 3.1 release candidate 1 released

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2020/jul/20/django-31-release-candidate-1-released/

--
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/f75cced2-299a-ff68-73b9-fd1dbf2368b8%40gmail.com.