Re: Feature Idea: Allow setting session cookie name dynamically

[Dan Strokirk]

Hi Carlton, thanks for the response.

An external package might be useful, although the code majority of the code 
would be the copied SessionMiddleware code and the tiny changes to allow a 
dynamic cookie name, so my thoughts is that this might be "too small" for a 
published pypi package?

But since I haven't found a similar request earlier on this mailing list or 
the issue tracker, it seems that it might be really niche, as you say!

Best regards,
Dan

-- 
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/01a91019-8d54-4322-a295-dbfdc12dfab9n%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Maciek Olko]

Hi Dan and Carlton,

In my current company I am impacted by conflicting session cookie name. We
have several internal tools built on Django, available in the internal
network under the same top-level domain. The scope of session cookies
apparently was set on more than one service to a wildcard. Majority of
users use only one of services in day-to-day work, so it's not impacting a
big number of people.

I personally would be +1 for exposing a method to easily and without
copying much code one was able to change it.

I wonder if using a Django project code name as part of session cookie for
new projects would have a potential to be considered as an accepted feature.

Kind regards,
Maciej

pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):

> Hi Carlton, thanks for the response.
>
> An external package might be useful, although the code majority of the
> code would be the copied SessionMiddleware code and the tiny changes to
> allow a dynamic cookie name, so my thoughts is that this might be "too
> small" for a published pypi package?
>
> But since I haven't found a similar request earlier on this mailing list
> or the issue tracker, it seems that it might be really niche, as you say!
>
> Best regards,
> Dan
>
> --
> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/CALYYG81HK-M2erdz4j5Jtp3h8J3vOaPj-qvE7rMPFRNiqKY1uA%40mail.gmail.com.

bulk_update() support for unique fields instead of only primary key

[Ebram Shehata]

I've already created a ticket that ended up with 'WONTFIX' here 
.
Please read it first.

The scenario that led me trying to add that feature:
Well, I'v a model that has a primary key and unique field...
Every  X period of time I've a cron that calls an external API to load 
updated data and store it in my Django project db.
Thing is I want to execute the update query without having to have the pk 
with me.. I already have the unique field in hand (got it from the API) and 
it should be enough to identify what object to be updated..

example code that will do so..

*# call external API and load data as list[dict]*
*objs = list()*
*for record in data:*
*# Just create instance of MyModel class with values needed..*
*objs.append(MyModel(my_unique_field=data['national_id'], name="New 
Name"))*

*# I expect to do:MyModel.objects.bulk_update(objs, fields=["name"], 
unique_field="my_unique_field")*

The current implementation requires every object to have its primary key 
set, but, that's not always the case. Also, if the primary key is 
my-django-project-generated, there's no way AFAIK to get those PKs without 
having to query them from DB, which will be a very expensive query to run 
if the data is large.

You can find the POC PR here: https://github.com/django/django/pull/15764

I really thing that'd be a very useful update to add.

I also have a question about this function: We can't use it to update 
primary keys.. I'm wondering why ? I want to also add that support to it.

-- 
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/f532b4fd-aba6-44dd-b373-e6e934ff8b67n%40googlegroups.com.

Re: bulk_update() support for unique fields instead of only primary key

[Jörg Breitbart]

Imho the pk field being treated special by bulk_update (as the only 
record filter predicate, non updatable) comes from one simple idea - 
stable object identity during the updates. For an ORM proper object 
identification is rather important to not mix things up, shifting 
identities might create havoc further down the road or in internal code, 
if it is not prepared to deal with identity shifts. Whether stable 
identities are really needed for bulk_update or could be lifted by 
making pk updatable I cannot tell for sure.


About record identification by another unique field - imho that should 
be safe as long as the unique field can sufficiently identify rows in 
question on a table. Implementation might get complicated in multi table 
inheritance, where the unqiue field may not reside on the target table 
itself (would need a similar tables+rows lookup expansion as done for pk).
Overall this sounds like a valuable API addition to bulk_update, whether 
it ultimately could lift the non updatable state of pk itself, remains 
uncertain (prolly needs tons of tests and a serious code review of some 
internals).


Cheers,
jerch

NB: Btw fetching proper pks upfront from some other unique field is 
typically very cheap compared to bulk_update runtime itself, given you 
have indexed those columns.



Am 07.06.22 um 02:15 schrieb Ebram Shehata:
I've already created a ticket that ended up with 'WONTFIX' here 
.

Please read it first.

The scenario that led me trying to add that feature:
Well, I'v a model that has a primary key and unique field...
Every  X period of time I've a cron that calls an external API to load 
updated data and store it in my Django project db.
Thing is I want to execute the update query without having to have the 
pk with me.. I already have the unique field in hand (got it from the 
API) and it should be enough to identify what object to be updated..


example code that will do so..

/# call external API and load data as list[dict]/
/objs = list()/
/for record in data:/
/    # Just create instance of MyModel class with values needed../
/    objs.append(MyModel(my_unique_field=data['national_id'], name="New 
Name"))/

/# I expect to do:
MyModel.objects.bulk_update(objs, fields=["name"], 
unique_field="my_unique_field")/


The current implementation requires every object to have its primary key 
set, but, that's not always the case. Also, if the primary key is 
my-django-project-generated, there's no way AFAIK to get those PKs 
without having to query them from DB, which will be a very expensive 
query to run if the data is large.


You can find the POC PR here: https://github.com/django/django/pull/15764

I really thing that'd be a very useful update to add.

I also have a question about this function: We can't use it to update 
primary keys.. I'm wondering why ? I want to also add that support to it.


--
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/f532b4fd-aba6-44dd-b373-e6e934ff8b67n%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/3a4655da-8205-48d3-5ae1-477168dcd444%40netzkolchose.de.