Cache framework

[Jure Erznožnik]

Apologies for wall of text, but it's a complex issue I'm raising. 
Hopefully you will see something you thought about in the recent past. I 
have also indented the rationalisation part, so if it's TL;DR, don't 
read it. Well, on with it:


I've lately had some dealings with Django caching framework that left me 
somewhat wanting. To be specific, these things stood out:


1. There is no listing function. It is impossible to enumerate keys
   matching a pattern
2. There are no synchronisation functions.
3. There is no default redis support

Proceeding with rationalisation:

   #1: Sometimes I just need records in the cache that would be easily
   iterable, easily insertable, but both with minimum locking / racing.
   An enumeration function would allow for easy retrieval of thusly
   inserted objects.

   This proposal is partly opposed by having support for atomic list
   operations, such as cache.append_to_list(key, items) and
   cache.pop_from_list(key, num_of_items). Such operations could be
   supported using #2

   Another possible approach might also be a cache.pop(key) function
   that would atomically retrieve current value and delete the cache
   entry at the same time. Such operation could also be supported using
   #2.

   #2: With complex data, there comes a need for synchronisation
   functions. The easiest to solve with existing commands, we have
   implemented a mutex class supporting "with Mutex('mutex_name'):" syntax.

   There was some debate within our team on what to do when even the
   cache is distributed among multiple cache servers, but we reached no
   consensus. It would definitely require a (separate) shared cache
   server, so maybe it's not really a huge problem as Django caching
   framework already supports that.

   #3: Current cache implementations in Django doesn't have redis support.

   I don't know whether that should be included or not, but even
   django-channels implements the channels backend with redis (and only
   redis), not with memcached. TBH I do not recall why we went with
   redis and not memcached when we were deciding infrastructure for our
   servers, but is seems the rationale we used lead to similar
   conclusion as that of django-channels developers.

   There was also a recent discussion debating obsoletness of memcached
   (i think, but did not verify just now) implementation. IIRC the
   problem was use of library that is no longer maintained while an
   up-to-date, well maintained alternative was available.

   Furthermore the django-channels redis backend is implemented such
   that it requires redis server 5.0 or greater (use of BZPOPMIN
   command). Ubuntu 18.04 LTS does not have this version in its apt
   archives. This I only mention as a curiosity as it's pretty easy to
   solve, but still, it was a nuisance requiring a workaround.

   I find it interesting that django-channels does not implement that
   channels backend with standard Django caching framework, but it
   seems it was inadequate at the time (hint: redis 5.0 requirement).
   Perhaps I should look up the discussion threads where channels
   developers were deciding this approach to see what made them decide
   for custom redis approach vs using the Django cache.

   TBH I find this one the hardest: there is third-party support for
   Redis caching in django. There must be a policy behind what cache
   backends should be supported and for some reason that policy has so
   far excluded Redis. However, I find it conflicting that
   django-channels would then only support Redis for some of its
   functionality. I hope I'm not going into politics too much here.


To finish up, is this something that Django core team would be willing 
to consider for improvement? If yes, I would be willing to provide 
relevant PRs (Django only), but I wanted to feel the general attitude 
towards the problem first.


To be clear, this is what I'm proposing to implement:

1. cache.list(pattern) returning matching cache entries. I would like
   the pattern to be regex compatible, but I have not done any analysis
   on listing support for existing backends yet.
2. hand over the Mutex class we implemented
3. quite frankly, I don't know what to do about this one. We're using
   django-redis package for our Redis backend, so I would hate to write
   something up from scratch. What is the standard approach with this,
   if support is decided by the core team?
4. While at it, I have seen that various backends now implement their
   own pickling. With the exception of memcached, they all implement
   the same thing. Perhaps it would be beneficial to move pickling
   functionality to BaseCache?

Thank you for your consideration,
Jure

--
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 

Re: Making max_length argument optional

[Tom Carrick]

I'm not a fan of any solution either, really, even the one I suggested.

I think adding a new kwarg, "unlimited" seems okay to me, though it feels a
little redundant.

I don't like the idea of using TextField, I find them semantically
different. An unlimited varchar says to me "one possibly very long thing",
whereas TextField feels more like it's free text, or a document, especially
as the form fields are different. Subclassing CharField is an option, but
the methods I've seen to do this makes it annoying. I need this so often
that I do it all the time, but the code is so short that I don't want to
bring in a new package to do it. Also, the popular ways to do this are not
great. One way is to just set the max_length extremely high, which is not
what I want ending up in the database, the other is something like this
, which
works well, but will stop working well once column collations are in as
that PR adds more stuff to CharField.__init__().

I think it's time we had something in Django, whatever that ends up being.

On Sun, 16 Aug 2020 at 20:28, Carlton Gibson 
wrote:

> Reading the history, I see an awful lot of -1s to the idea of a default.
>
> I see “use a TextField” and “use a subclass” a few times, which were my
> immediate thoughts just on the recent emails.
>
> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>
>> I’m not a fan of implicit max_lengths. Is having to add a keyword
>> argument to a model field really that much of a burden? And we also would
>> likely never be able to change the default without headaches.
>>
>> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>>
>> I'd like to revive this discussion and try to come to a consensus as it's
>> something I find myself wishing for (for Postgres in particular).
>>
>> My suggestion, after reading through everything:
>>
>> Give CharField a default max_length that is consistent across all
>> vendors. It doesn't really matter what the number is other than that it
>> should be large enough to be useful but small enough to work everywhere. I
>> think 100 or 255 are both fine options.
>>
>> If you set max_length=None explicitly, on Postgres this will use an
>> unlimited varchar, on everything else will raise an exception on migrate.
>>
>> Any thoughts?
>>
>> Cheers,
>> Tom
>>
>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>>
>>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>>>
>>>
>>> > I’m not too keen on a contrib.pg field. CharField is the base class
>>> of many
>>>
>>>
>>> > fields, a __init__ kwarg approach such as max_length=None allows us to
>>>
>>>
>>> > reach those as well.
>>>
>>>
>>> >
>>>
>>>
>>>
>>>
>>>
>>> That's a good point; Can we enable max_length=None in a mixin?
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>>
>>
>> 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/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%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/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es
>> 
>> .
>>
>>
>> --
> 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/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%40mail.gmail.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.goo

Re: Making max_length argument optional

[Carlton Gibson]

Would the subclass in contrib.postgres suggestion be acceptable?

On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:

> I'm not a fan of any solution either, really, even the one I suggested.
>
> I think adding a new kwarg, "unlimited" seems okay to me, though it feels
> a little redundant.
>
> I don't like the idea of using TextField, I find them semantically
> different. An unlimited varchar says to me "one possibly very long thing",
> whereas TextField feels more like it's free text, or a document, especially
> as the form fields are different. Subclassing CharField is an option, but
> the methods I've seen to do this makes it annoying. I need this so often
> that I do it all the time, but the code is so short that I don't want to
> bring in a new package to do it. Also, the popular ways to do this are not
> great. One way is to just set the max_length extremely high, which is not
> what I want ending up in the database, the other is something like this
> , which
> works well, but will stop working well once column collations are in as
> that PR adds more stuff to CharField.__init__().
>
> I think it's time we had something in Django, whatever that ends up being.
>
> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson 
> wrote:
>
>> Reading the history, I see an awful lot of -1s to the idea of a default.
>>
>> I see “use a TextField” and “use a subclass” a few times, which were my
>> immediate thoughts just on the recent emails.
>>
>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>>
>>> I’m not a fan of implicit max_lengths. Is having to add a keyword
>>> argument to a model field really that much of a burden? And we also would
>>> likely never be able to change the default without headaches.
>>>
>>> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>>>
>>> I'd like to revive this discussion and try to come to a consensus as
>>> it's something I find myself wishing for (for Postgres in particular).
>>>
>>> My suggestion, after reading through everything:
>>>
>>> Give CharField a default max_length that is consistent across all
>>> vendors. It doesn't really matter what the number is other than that it
>>> should be large enough to be useful but small enough to work everywhere. I
>>> think 100 or 255 are both fine options.
>>>
>>> If you set max_length=None explicitly, on Postgres this will use an
>>> unlimited varchar, on everything else will raise an exception on migrate.
>>>
>>> Any thoughts?
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>>>
 On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:


 > I’m not too keen on a contrib.pg field. CharField is the base class
 of many


 > fields, a __init__ kwarg approach such as max_length=None allows us to


 > reach those as well.


 >





 That's a good point; Can we enable max_length=None in a mixin?



>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> 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/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%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/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es
>>> 
>>> .
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> 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/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%40mail.gmail.com
>> 
>> .
>>
>>
>>
>
>
>
>
>
>

include_block template tag

[Jure Erznožnik]

While rendering templates we often come into situations where data 
remains the same, but sometimes we want to render it one way, other 
times - another.


Examples:

a library supporting various CSS frameworks. You would always render 
panel  
title and panel body, but bootstrap does it using one HTML, material 
uses another.


you may decide to render a piece of data in a panel, input, table cell, etc.

analysis:

There's a huge note with include tag 
 
clarifying how include tag is NOT used for purposes listed above. This 
leads me to believe (but I have not researched it thoroughly) that the 
question has been asked many times before.


proposal:

implement support for passing HTML renders into an included template.

I see two possible approaches for this:

Approach 1 template example:

   {% includeblock template with ... %}
    {% subblock block1 %}
 HTML code
    {% endsubblock %}
    {% subblock block2 %}
 HTML code
    {% endsubblock %}
   {% endincludeblock %}

block1 and block2 would be blocks defined in template using existing 
block syntax. I'm not sure if recycling existing block tag would be 
possible in this context, but I would certainly prefer to avoid new 
template tag syntax. Basically what this tag would do is first evaluate 
the subblocks, then override the blocks defined in the template, then 
render the template.


Approach 2 template example:

   {% block block1 as block1_var %}
   HTML code
   {% endblock %}
   {% subblock block2 %}
   HTML code
   {% endsubblock %}
   {% include template with block1=block1_var block2=block2_var %}

This approach is a bit less structured than the first one, but it 
requires a lot less modification. Basically it would only add the with 
parameter to store block render in a variable instead of actually 
rendering it to output. Possible problem with block inheritance within 
the template.



Would either of the above be interesting to include in Django templating 
code?


Thanks for your consideration,
Jure

--
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/2b317d14-f8e1-c47d-4883-ff06040d1204%40gmail.com.

Re: Making max_length argument optional

[Tom Carrick]

It would work for my use-cases. It was mentioned that it's maybe not the
best as a lot of fields subclass CharField, but I don't see a compelling
argument for an unlimited email or slug field. The one problem I see is
CICharField, you might want to make that unlimited - but the CI fields are
more or less redundant on pg >= 12 once we have column collations in. So I
think it's okay for now. Only problem I can see is if we add more CharField
subclasses in the future...

On Mon, 17 Aug 2020 at 11:02, Carlton Gibson 
wrote:

> Would the subclass in contrib.postgres suggestion be acceptable?
>
> On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:
>
>> I'm not a fan of any solution either, really, even the one I suggested.
>>
>> I think adding a new kwarg, "unlimited" seems okay to me, though it feels
>> a little redundant.
>>
>> I don't like the idea of using TextField, I find them semantically
>> different. An unlimited varchar says to me "one possibly very long thing",
>> whereas TextField feels more like it's free text, or a document, especially
>> as the form fields are different. Subclassing CharField is an option, but
>> the methods I've seen to do this makes it annoying. I need this so often
>> that I do it all the time, but the code is so short that I don't want to
>> bring in a new package to do it. Also, the popular ways to do this are not
>> great. One way is to just set the max_length extremely high, which is not
>> what I want ending up in the database, the other is something like this
>> , which
>> works well, but will stop working well once column collations are in as
>> that PR adds more stuff to CharField.__init__().
>>
>> I think it's time we had something in Django, whatever that ends up being.
>>
>> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson 
>> wrote:
>>
>>> Reading the history, I see an awful lot of -1s to the idea of a default.
>>>
>>> I see “use a TextField” and “use a subclass” a few times, which were my
>>> immediate thoughts just on the recent emails.
>>>
>>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>>>
 I’m not a fan of implicit max_lengths. Is having to add a keyword
 argument to a model field really that much of a burden? And we also would
 likely never be able to change the default without headaches.

 On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:

 I'd like to revive this discussion and try to come to a consensus as
 it's something I find myself wishing for (for Postgres in particular).

 My suggestion, after reading through everything:

 Give CharField a default max_length that is consistent across all
 vendors. It doesn't really matter what the number is other than that it
 should be large enough to be useful but small enough to work everywhere. I
 think 100 or 255 are both fine options.

 If you set max_length=None explicitly, on Postgres this will use an
 unlimited varchar, on everything else will raise an exception on migrate.

 Any thoughts?

 Cheers,
 Tom

 On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:

> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>
>
> > I’m not too keen on a contrib.pg field. CharField is the base class
> of many
>
>
> > fields, a __init__ kwarg approach such as max_length=None allows us
> to
>
>
> > reach those as well.
>
>
> >
>
>
>
>
>
> That's a good point; Can we enable max_length=None in a mixin?
>
>
>




 --


 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/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%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/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es
 
 .



>>>
>>>
>>>
>

Re: Cache framework

[Adam Johnson]

Hi Jure

The caching framework exists mostly to provide a memcached-like API.
Memcached does not support either of your two first options - there's no
efficient way to list keys, nor does it make any atomicity guarantees
(outside of a single key). I think for most applications you'll find it
easier and more reliable to use a database model if you need such
operations. The overhead of using a database is not much compared to the
stronger guarantees you want - I made an efficient MySQL-based cache
backend which comes in at only ~50% of the speed of memcached, despite
writing to disk (
https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/
). (Additionally your proposal to use a regex can *never* perform well in
the general case, since some regexes have terrible performance
characteristics.)

In terms of the third option, I think most people using redis with the
caching framework happily use django-redis. It's well maintained and has
1.8k stars on GitHub. I don't see any compelling reason to merge it to core
right now, plus that always slows down a project's progression. Channels
uses redis through its channels-redis package, and it needs redis pub-sub
operations, which are quite different to caching. This is a fundamentally
different problem to caching, and it only happens that Redis supports both.
Channels can use other layers backends - I'm not sure of existing
alternatives, but they could use e.g. Postgres' NOTIFY, Google PubSub, AWS
SNS, etc.

There are some memcached features which the cache API doesn't currently
support, such as compare-and-set. I'd be interested in seeing those added
to core.

Thanks,

Adam

On Mon, 17 Aug 2020 at 09:30, Jure Erznožnik 
wrote:

> Apologies for wall of text, but it's a complex issue I'm raising.
> Hopefully you will see something you thought about in the recent past. I
> have also indented the rationalisation part, so if it's TL;DR, don't read
> it. Well, on with it:
>
> I've lately had some dealings with Django caching framework that left me
> somewhat wanting. To be specific, these things stood out:
>
>1. There is no listing function. It is impossible to enumerate keys
>matching a pattern
>2. There are no synchronisation functions.
>3. There is no default redis support
>
> Proceeding with rationalisation:
>
> #1: Sometimes I just need records in the cache that would be easily
> iterable, easily insertable, but both with minimum locking / racing. An
> enumeration function would allow for easy retrieval of thusly inserted
> objects.
>
> This proposal is partly opposed by having support for atomic list
> operations, such as cache.append_to_list(key, items) and
> cache.pop_from_list(key, num_of_items). Such operations could be supported
> using #2
>
> Another possible approach might also be a cache.pop(key) function that
> would atomically retrieve current value and delete the cache entry at the
> same time. Such operation could also be supported using #2.
>
> #2: With complex data, there comes a need for synchronisation functions.
> The easiest to solve with existing commands, we have implemented a mutex
> class supporting "with Mutex('mutex_name'):" syntax.
>
> There was some debate within our team on what to do when even the cache is
> distributed among multiple cache servers, but we reached no consensus. It
> would definitely require a (separate) shared cache server, so maybe it's
> not really a huge problem as Django caching framework already supports that.
>
> #3: Current cache implementations in Django doesn't have redis support.
>
> I don't know whether that should be included or not, but even
> django-channels implements the channels backend with redis (and only
> redis), not with memcached. TBH I do not recall why we went with redis and
> not memcached when we were deciding infrastructure for our servers, but is
> seems the rationale we used lead to similar conclusion as that of
> django-channels developers.
>
> There was also a recent discussion debating obsoletness of memcached (i
> think, but did not verify just now) implementation. IIRC the problem was
> use of library that is no longer maintained while an up-to-date, well
> maintained alternative was available.
>
> Furthermore the django-channels redis backend is implemented such that it
> requires redis server 5.0 or greater (use of BZPOPMIN command). Ubuntu
> 18.04 LTS does not have this version in its apt archives. This I only
> mention as a curiosity as it's pretty easy to solve, but still, it was a
> nuisance requiring a workaround.
>
> I find it interesting that django-channels does not implement that
> channels backend with standard Django caching framework, but it seems it
> was inadequate at the time (hint: redis 5.0 requirement). Perhaps I should
> look up the discussion threads where channels developers were deciding this
> approach to see what made them decide for custom redis approach vs using
> the Django cache.
>
> TBH I find this one the hardes

Re: Cache framework

[Carlton Gibson]

> On 17 Aug 2020, at 11:32, Adam Johnson  wrote:
> 
> Channels can use other layers backends - I'm not sure of existing 
> alternatives, but they could use e.g. Postgres' NOTIFY, Google PubSub, AWS 
> SNS, etc.

The only other active channel layer backend that I’m aware of is for RabbitMQ: 
https://github.com/CJWorkbench/channels_rabbitmq/

-- 
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/6EEE4A46-A2AF-47C2-8BE7-CADACBF30D83%40gmail.com.

Pickling - Re: Cache framework

[Roger Gammans]

On Mon, 2020-08-17 at 10:30 +0200, Jure Erznožnik wrote:
> While at it, I have seen that various backends now implement
>   their own pickling. With the exception of memcached, they
> all
>   implement the same thing. Perhaps it would be beneficial to
>   move pickling functionality to BaseCache?
> 
> 
>   
>   

I've noticed in my applications when I've used django cache in
performance sensitive hot paths, often it shifts he slowest portion
from the databases (or whatever I'm caching) to the unpickler. 

This makes me wonder if there is a argument to abstract the pickling,
so that application can do something special in their uses case.


-- 
Roger Gammans 
Gamma Science Ltd. (GB Nr. 07356014 )

-- 
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/e619056268f40c4d909daf5cddf47885a8cc6cdf.camel%40gammascience.co.uk.

Re: Fellow Reports - August 2020

[Mariusz Felisiak]

Week ending August 16, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31870 - App with 
default_app_config and without apps.py or with an empty apps.py crashes. 
(accepted)
https://code.djangoproject.com/ticket/31872 - Postgres 
DecimalRangeField ignores bounds (wontfix)
https://code.djangoproject.com/ticket/31873 - Count in query giving 
undesired results across models (invalid)
https://code.djangoproject.com/ticket/31871 - SESSION_COOKIE_SAMESITE 
comment in global_settings is outdated. (accepted)
https://code.djangoproject.com/ticket/31869 - Improving data migration 
using `dumpdata` and `loaddata` (wontfix)
https://code.djangoproject.com/ticket/31874 - FK id is not used in 
update_or_create when id is not used directly (worksforme)
https://code.djangoproject.com/ticket/31876 - UserManager._create_user 
does not respect USERNAME_FIELD. (invalid)
https://code.djangoproject.com/ticket/31877 - 
TemplateView.get_context_data()'s kwargs returns SimpleLazyObjects that 
causes a crash when filtering. (accepted)
https://code.djangoproject.com/ticket/31878 - Default username in 
createsuperuser command doesn't respect the --database option. (accepted)
https://code.djangoproject.com/ticket/31882 - JSONField for SQLite on 
macos - cannot set DYLD_LIBRARY_PATH (invalid)
https://code.djangoproject.com/ticket/31880 - QuerySet.aggregate() 
mixes annotated fields names. (accepted) 
https://code.djangoproject.com/ticket/31887 - OperationalError: (2006, 
'MySQL server has gone away') (invalid)
https://code.djangoproject.com/ticket/31888 - Test loader accesses 
MySQL before database is created. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/13288 - Fixed #31871 -- Updated 
SESSION_COOKIE_SAMESITE comment in global_settings.py.
https://github.com/django/django/pull/13287 - Fixed #31870 -- Fixed 
crash when populating app registry with empty or without apps module.
https://github.com/django/django/pull/13283 - Fixed #31866 -- Fixed 
locking proxy models in QuerySet.select_for_update(of=())
https://github.com/django/django/pull/13284 - Fixed #21181 -- Added 
Collate database function. 
https://github.com/django/django/pull/13281 - Fixed #31863 -- Prevented 
mutating model state by copies of model instances.
https://github.com/django/django/pull/13295 - Fixed #31382 -- Made 
Model.save(update_fields=...) raise ValueError on non-concrete fields.
https://github.com/django/django/pull/13297 - Fixes #31877 -- Used 
lazy() for TemplateView kwarg deprecation warning.
https://github.com/django/django/pull/13236 - Fixed #31825 -- Made 
RenameField operation a noop for fields with db_column.
https://github.com/django/django/pull/13300 - Fixed #31792 -- Made 
Exists() reuse QuerySet.exists() optimizations.
https://github.com/django/django/pull/13301 - Fixed #31878 -- Made 
createsuperuser respect --database option in default usernames.
https://github.com/django/django/pull/13302 - Removed unnecessary 
urlsplit() call and added missing items to __all__.
https://github.com/django/django/pull/13237 - Fixed #31826 -- Made 
AlterField operation a noop when adding db_column.

*Reviewed:*
https://github.com/django/django/pull/13292 - Fixed #31865 -- Adjusted 
admin sidebar template to reduce debug logging.
https://github.com/django/django/pull/13224 - Fixed #31811 -- Added 
optional timing outputs to the test runner.

*Authored:*
https://github.com/django/djangoproject.com/pull/1017 - Update isort, 
Python, and PostgreSQL.

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/8870288d-49df-4488-8f1b-7146a2cc3d75n%40googlegroups.com.

Re: include_block template tag

[Curtis Maloney]

Interesting ideas... and looks similar to some of the features I put into 
Sniplates: https://sniplates.readthedocs.io/en/latest/

If you like we can work on adding this to sniplates, if it's not accepted into 
core.

--
Curtis


On Mon, 17 Aug 2020, at 19:05, Jure Erznožnik wrote:
> While rendering templates we often come into situations where data remains 
> the same, but sometimes we want to render it one way, other times - another.

> Examples:

> a library supporting various CSS frameworks. You would always render panel 
>  title and 
> panel body, but bootstrap does it using one HTML, material uses another.

> you may decide to render a piece of data in a panel, input, table cell, etc.

> analysis:

> There's a huge note with include tag 
>  
> clarifying how include tag is NOT used for purposes listed above. This leads 
> me to believe (but I have not researched it thoroughly) that the question has 
> been asked many times before.

> proposal:

> implement support for passing HTML renders into an included template.

> I see two possible approaches for this:

> Approach 1 template example:

>> {% includeblock template with ... %}
>> {% subblock block1 %}
>>  HTML code
>> {% endsubblock %}
>> {% subblock block2 %}
>>  HTML code
>> {% endsubblock %}
>> {% endincludeblock %}
> block1 and block2 would be blocks defined in template using existing block 
> syntax. I'm not sure if recycling existing block tag would be possible in 
> this context, but I would certainly prefer to avoid new template tag syntax. 
> Basically what this tag would do is first evaluate the subblocks, then 
> override the blocks defined in the template, then render the template.

> Approach 2 template example:

>> {% block block1 as block1_var %}
>>HTML code
>> {% endblock %}
>> {% subblock block2 %}
>>HTML code
>> {% endsubblock %}
>> {% include template with block1=block1_var block2=block2_var %}
> This approach is a bit less structured than the first one, but it requires a 
> lot less modification. Basically it would only add the with parameter to 
> store block render in a variable instead of actually rendering it to output. 
> Possible problem with block inheritance within the template.

> 

> Would either of the above be interesting to include in Django templating code?


> Thanks for your consideration,
> Jure

> 

> --
> 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/2b317d14-f8e1-c47d-4883-ff06040d1204%40gmail.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/5d52e091-9fd9-49da-9e5e-f3a61a22c6e8%40www.fastmail.com.