Re: general interest in faster bulk_update implementation

[Jörg Breitbart]

@Mariusz

Thx for the update on the db support roadmap, helps alot to get things 
into perspective.



@expression support
After a few more tests it turns out, that expression support prolly can 
be saved exactly as it is by a combination of the current CASE chaining 
with the VALUES table. At least sqlite and postgres support the 
following format (mysql variants not tested yet):


UPDATE table SET f1 = CASE pk=1 THEN f2 ELSE foo.column2 END FROM 
(VALUES (1, NULL), (2, 'Hello')) AS foo where table.pk = foo.column1;


This would be the result from something like
bulk_update([
  Model(pk=1, f1=F('f2')),
  Model(pk=..., f1=),
  ...], ['f1'])

This again introduces the bad runtime of the CASE chains into the 
statement, but only for objects using expression fields, so the user has 
limited control over the runtime needs (dont use expressions if you want 
very fast value pumping...)


Advantage of this - it should do exactly the same updates as the 
bulk_update implementation (no weird ordering side effects), thus it 
gets alot easier to prove, that the fast and fallback code path exhibit 
the same update behavior.



Cheers,
jerch

--
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/754232be-68e1-1472-7371-2195688b32fa%40netzkolchose.de.

Re: Provide a way to pass kwargs when initializing the storage class

[Carlton Gibson]

Hi Jarosław. Thanks for picking this up. 

There seems to be enough support for the general idea here, so worth 
pressing on. 

Let's think about any required deprecations on the PR. (It's easier there 
). 

Kind Regards,

Carlton

On Sunday, 24 April 2022 at 01:25:28 UTC+2 jaro...@wygoda.me wrote:

>  I'd like to introduce a file storage registry similar to 
> BaseConnectionHandler (django/utils/connection.py) and EngineHandler 
> (django/template/utils.py).
>
> Example settings.py snippet:
>
> STORAGES = {  # rename to FILE_STORAGES to make it more explictit?
> 'example': {
> 'BACKEND': 'django.core.files.storage.FileSystemStorage',
> 'OPTIONS': {
> 'location': '/example',
> 'base_url': '/example/',
> },
> },
> }
>
> Changes introduced by this pr are backward compatible. Users can still use 
> existing settings to configure static and media storages.
>
> Currently storages can be retrieved from the following objects:
>
> django/core/files/storage.py:
>
> get_storage_class
> DefaultStorage
> default_storage 
>
> django/contrib/staticfiles/storage.py:
>
> ConfiguredStorage
> staticfiles_storage 
>
> What do you think about deprecating them?
>
> ​https://github.com/django/django/pull/15610
>
> FileField can be tackled in a separate pr.
>
> czwartek, 12 listopada 2015 o 11:25:57 UTC+1 ja...@tartarus.org 
> napisał(a):
>
>> On 8 Nov 2015, at 08:31, Marc Tamlyn  wrote: 
>>
>> > I'm definitely in favour of a format allowing multiple storage back 
>> ends referred to by name. For larger sites it is not unusual to manage 
>> files across multiple locations (eg several S3 buckets). The storage param 
>> to FileField would be allowed to be the key, and there would be a 
>> get_storage function like get_cache. 
>>
>> It would remove the assymetry between the default backends and per-field 
>> ones, which does feel a little odd. However I don’t think that’s a strong 
>> enough reason to go for more complicated. Ballooning dictionaries can feel 
>> overwhelming when looking at modern Django settings (for instance, the new 
>> templates configuration is more daunting than it used to be), and as 
>> pointed out, overriding is more fiddly. 
>>
>> For testing, you need to be explicit per-field no matter what, so it’s a 
>> change from an instance to a symbolic reference. The instance is probably a 
>> variable anyway by declaration of the test model, which I suspect is 
>> slightly easier to chase. 
>>
>> So I’d be slightly more in favour of the terse, tuple-based syntax. 
>>
>> J 
>>
>> -- 
>> James Aylett 
>> I make: devfort.com, spacelog.org 
>> Films: talktorex.co.uk 
>> Everything else: tartarus.org/james/ 
>>
>>

-- 
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/48fed52b-4ef4-49d2-8e8d-c3f8550a4731n%40googlegroups.com.