Re: cache middleware on multi sites...

[sergey]

I create my own slightly changed cache middleware (replace get_full_path to 
build_absolute_uri)
http://macrotoma.blogspot.com/2012/06/custom-multisite-caching-on-django.html
 

четверг, 19 ноября 2009 г., 13:16:52 UTC+2 пользователь jens написал:
>
> There exist some "intersection" on multi site installation, if i use 
> django.middleware.cache.UpdateCacheMiddleware and 
> django.middleware.cache.FetchFromCacheMiddleware 
>
> Problem: 
> The cache key would be only generated based on the url without the 
> domain name. So if the page /foobar/ exist on site A and site B but 
> with different content, they would be only caches one time. 
>
> Solutions: 
> 1. The user can insert this into his settings: 
> CACHE_MIDDLEWARE_KEY_PREFIX = "FooBar %s" % SITE_ID 
>
> 2. Django should insert the SITE_ID into cache key. e.g. in 
> django.utils.cache.get_cache_key() 
>
> 3. Django should use the complete path to build the cache key. e.g.: 
> use request.build_absolute_uri() in 
> django.utils.cache._generate_cache_header_key() instead of iri_to_uri 
> (request.path) 
>
> Mfg. 
>
> Jens Diemer 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/2mh_p3Uihp0J.
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.

Django Templates and BOM (byte order marks)

[Sergey Kirillov]

Greetings,

While researching strange IE behaviour at some pages of my
Django-powered site I've found that Django does not handle BOM marks
correctly.

For instance I have following templates (!UTF_8_BOM! = EF BB BF):

--- base.html
!UTF_8_BOM!http://www.w3.org/TR/html4/loose.dtd";>
blah-blah-blah
---

and

--- page.html
!UTF_8_BOM!
{% extends "base.html" %}
blah-blah-blah
---

If I will render page.html output will contain TWO byte order marks:
!UTF_8_BOM!!UTF8_BOM!http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django Templates and BOM (byte order marks)

[Sergey Kirillov]

James Bennett написав:
> On 12/8/06, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
> > For instance I have following templates (!UTF_8_BOM! = EF BB BF):
>
> Sort of off-topic, but why are you using a BOM in UTF-8? ;)

Well, I'm not ;)

But I had few legacy templates created in Notepad, and I see that
Notepad inserts BOM marks automatically.

I think correct behavior, for template loader, will be to check default
encoding, and if it is UTF8 (or other BOMable) remove BOM.


--~--~-~--~~~---~--~~
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Django ORM

[Sergey Kirillov]

Greetings,

I'd like to ask, why Django ORM has no concept of Identity Map? It is
strange for me that if I call get() five times I will get five object
instances, instead of five references to a single instance.

Was it a design decision? I'm unable to find any discussions of this.
Or I'm the first one who asks about this?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Site object in django.contrib.contenttypes.views.shortcut

[Sergey Belov]

Hello!

We must not try to select Site object from DB in
django.contrib.contenttypes.views.shortcut if no Site model is
installed.
Can somebody pay some attention to this ticket, review and may be
commit one-liner patch? =)
http://code.djangoproject.com/ticket/11129

Thank you!

--
Best regards,
Sergey Belov

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

Yaml serializer output

[Sergey Fursov]

Hi there,

Before opening a ticket I would like to discuss my problem here.

Django docs say:

```
YAML¶ <https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml> 

YAML serialization looks quite similar to JSON. The object list is 
serialized as a sequence mappings with the keys “pk”, “model” and “fields”. 
Each field is again a mapping with the key being name of the field and the 
value the value:
- fields: {expire_date: !!timestamp '2013-01-16 08:16:59.844560+00:00'} 
model: sessions.session pk: 4b678b301dfd8a4e0dad910de3ae245b 
```
https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml

But I cannot find a way to produce the same output. Both available to me 
environments (MacOS and Debian linux inside a Docker container) product a 
simpler output, like

```
>> obj = core.ModelA.objects.get(id=1)
>> print(serializers.serialize('yaml', [obj]))
- model: core.modela
  pk: 1
  fields:
created: 2017-02-05 16:11:44.310613+00:00
 other fields ...
```

I've found this after running full Django test suite when 6 test from 
django/tests/timezones/tests.py failed. Example failure:

```
FAIL: test_naive_datetime_with_microsecond 
(timezones.tests.SerializationTests)
--
Traceback (most recent call last):
  File "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", 
line 671, in test_naive_datetime_with_microsecond
self.assert_yaml_contains_datetime(data, "2011-09-01 13:20:30.405060")
  File "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", 
line 625, in assert_yaml_contains_datetime
self.assertRegex(yaml, r"\n  fields: {dt: !(!timestamp)? '%s'}" % 
re.escape(dt))
AssertionError: Regex didn't match: "\\n  fields: {dt: !(!timestamp)? 
'2011\\-09\\-01\\ 13:20:30\\.405060'}" not found in '- model: 
timezones.event\n  pk: null\n  fields:\ndt: 2011-09-01 
13:20:30.405060\n'
```

I've tried to install several different pyyaml versions (from 6.0 down to 
5.1.2).

Do I miss something or it is a valid issue for opening a ticket?

Thanks,
Sergey Fursov

-- 
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/1dfa6764-a63d-4233-be5d-2f0a6bdeecdan%40googlegroups.com.

Re: Yaml serializer output

[Sergey Fursov]

Please, disregard the part about failing tests, I had an old version 
locally without this commit applied 
https://github.com/django/django/commit/a57c783dd4e6dc73847081221827a1902eede88b
Anyway, I think it might be confusing (at least it is confusing to me) that 
by default yaml serializer produces a different output than provided in docs

воскресенье, 26 декабря 2021 г. в 22:21:42 UTC+3, Sergey Fursov: 

> Hi there,
>
> Before opening a ticket I would like to discuss my problem here.
>
> Django docs say:
>
> ```
> YAML¶ <https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml> 
>
> YAML serialization looks quite similar to JSON. The object list is 
> serialized as a sequence mappings with the keys “pk”, “model” and “fields”. 
> Each field is again a mapping with the key being name of the field and the 
> value the value:
> - fields: {expire_date: !!timestamp '2013-01-16 08:16:59.844560+00:00'} 
> model: sessions.session pk: 4b678b301dfd8a4e0dad910de3ae245b 
> ```
> https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml
>
> But I cannot find a way to produce the same output. Both available to me 
> environments (MacOS and Debian linux inside a Docker container) product a 
> simpler output, like
>
> ```
> >> obj = core.ModelA.objects.get(id=1)
> >> print(serializers.serialize('yaml', [obj]))
> - model: core.modela
>   pk: 1
>   fields:
> created: 2017-02-05 16:11:44.310613+00:00
>  other fields ...
> ```
>
> I've found this after running full Django test suite when 6 test from 
> django/tests/timezones/tests.py failed. Example failure:
>
> ```
> FAIL: test_naive_datetime_with_microsecond 
> (timezones.tests.SerializationTests)
> --
> Traceback (most recent call last):
>   File "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", 
> line 671, in test_naive_datetime_with_microsecond
> self.assert_yaml_contains_datetime(data, "2011-09-01 13:20:30.405060")
>   File "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", 
> line 625, in assert_yaml_contains_datetime
> self.assertRegex(yaml, r"\n  fields: {dt: !(!timestamp)? '%s'}" % 
> re.escape(dt))
> AssertionError: Regex didn't match: "\\n  fields: {dt: !(!timestamp)? 
> '2011\\-09\\-01\\ 13:20:30\\.405060'}" not found in '- model: 
> timezones.event\n  pk: null\n  fields:\ndt: 2011-09-01 
> 13:20:30.405060\n'
> ```
>
> I've tried to install several different pyyaml versions (from 6.0 down to 
> 5.1.2).
>
> Do I miss something or it is a valid issue for opening a ticket?
>
> Thanks,
> Sergey Fursov
>

-- 
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/6793d234-92f5-46fa-bc19-3996626dc456n%40googlegroups.com.

Re: Yaml serializer output

[Sergey Fursov]

Sorry, I forgot to mention here the PR I made -
https://github.com/django/django/pull/15242

On Tue, Dec 28, 2021, 14:13 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> I've made a PR to update the docs:
> https://github.com/django/django/pull/15250
>
> On Mon, 27 Dec 2021 at 08:13, Sergey Fursov  wrote:
>
>> Please, disregard the part about failing tests, I had an old version
>> locally without this commit applied
>> https://github.com/django/django/commit/a57c783dd4e6dc73847081221827a1902eede88b
>> Anyway, I think it might be confusing (at least it is confusing to me)
>> that by default yaml serializer produces a different output than provided
>> in docs
>>
>> воскресенье, 26 декабря 2021 г. в 22:21:42 UTC+3, Sergey Fursov:
>>
>>> Hi there,
>>>
>>> Before opening a ticket I would like to discuss my problem here.
>>>
>>> Django docs say:
>>>
>>> ```
>>> YAML¶ <https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml>
>>>
>>> YAML serialization looks quite similar to JSON. The object list is
>>> serialized as a sequence mappings with the keys “pk”, “model” and “fields”.
>>> Each field is again a mapping with the key being name of the field and the
>>> value the value:
>>> - fields: {expire_date: !!timestamp '2013-01-16 08:16:59.844560+00:00'}
>>> model: sessions.session pk: 4b678b301dfd8a4e0dad910de3ae245b
>>> ```
>>> https://docs.djangoproject.com/en/4.0/topics/serialization/#yaml
>>>
>>> But I cannot find a way to produce the same output. Both available to me
>>> environments (MacOS and Debian linux inside a Docker container) product a
>>> simpler output, like
>>>
>>> ```
>>> >> obj = core.ModelA.objects.get(id=1)
>>> >> print(serializers.serialize('yaml', [obj]))
>>> - model: core.modela
>>>   pk: 1
>>>   fields:
>>> created: 2017-02-05 16:11:44.310613+00:00
>>>  other fields ...
>>> ```
>>>
>>> I've found this after running full Django test suite when 6 test from
>>> django/tests/timezones/tests.py failed. Example failure:
>>>
>>> ```
>>> FAIL: test_naive_datetime_with_microsecond
>>> (timezones.tests.SerializationTests)
>>> --
>>> Traceback (most recent call last):
>>>   File
>>> "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", line
>>> 671, in test_naive_datetime_with_microsecond
>>> self.assert_yaml_contains_datetime(data, "2011-09-01
>>> 13:20:30.405060")
>>>   File
>>> "/Users/geyser/coding/opensource/django/tests/timezones/tests.py", line
>>> 625, in assert_yaml_contains_datetime
>>> self.assertRegex(yaml, r"\n  fields: {dt: !(!timestamp)? '%s'}" %
>>> re.escape(dt))
>>> AssertionError: Regex didn't match: "\\n  fields: {dt: !(!timestamp)?
>>> '2011\\-09\\-01\\ 13:20:30\\.405060'}" not found in '- model:
>>> timezones.event\n  pk: null\n  fields:\ndt: 2011-09-01
>>> 13:20:30.405060\n'
>>> ```
>>>
>>> I've tried to install several different pyyaml versions (from 6.0 down
>>> to 5.1.2).
>>>
>>> Do I miss something or it is a valid issue for opening a ticket?
>>>
>>> Thanks,
>>> Sergey Fursov
>>>
>> --
>> 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/6793d234-92f5-46fa-bc19-3996626dc456n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6793d234-92f5-46fa-bc19-3996626dc456n%40googlegroups.com?utm_medium=email&utm_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/CAMyDDM1JV95MzE0cOziaYQ17kMMDEBTCJBkTaPkphZQFqdaeiw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1JV95MzE0cOziaYQ17kMMDEBTCJBkTaPkphZQFqdaeiw%40mail.gmail.com?utm_medium=email&utm_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/CAG-zk-BGtwLNa2gA_NHwonAEoxie3T4uVN6GF%3DrKQANwJQqxhw%40mail.gmail.com.

Re: Feature request: get_first_or_404

[Sergey Fedoseev]

IMO it shouldn't be added to Django because the same thing can be done in 
one line: get_object_or_404(qs[:1]), but we could add such using to 
get_object_or_404() docs.

On Wednesday, November 29, 2017 at 3:41:54 AM UTC+5, Piotr Domański wrote:
>
> Currently we have get_object_or_404 and get_list_or_404 but sometimes we 
> just want to get first matching record for some criteria.
> If criteria aren't unique then get_object_or_404 raises 
> MultipleObjectsReturned so request ends with internal server error.
>
> My idea is to add function which returns just first matching element and 
> ends with 404 if no elements match.
> This function will have parameter order_by (optional or required) of type 
> List['str'] 
> which determines which element choose first if there are many matching 
> elements.
>
> In my opinion addition of this feature is good idea, because it is useful 
> and safe for Django framework.
>

-- 
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/37de282e-61eb-46f6-9e7e-f7807594bb50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ease patching Django object behavior in another django packages

[Sergey Glazyrin]

Hello guys!
I faced a situation when auth backend needs access to request object inside 
of get_user auth backend function

https://code.djangoproject.com/ticket/29005

I can patch it following way (function to be patched is 
django.contrib.auth.get_user)


def get_user(request):
>
 

..
> code
> .
>  backend = load_backend(backend_path)
>  backend,request = request
> .
> code
> .



But I don't like this solution because I'll need to keep my eyes on this 
monkey patch while django upgrade, etc, and it's very dirty hack.

Instead I propose to extend django behaviour using design pattern Builder 
to simplify integration of another apps into django object internals (it 
sounds hacky, but it's safe and simple to implement)

with change I proposed, the patch would be done on django level, we need to 
add

def get_user(request):
>
> ...
> code
> ...
>
>  backend = load_backend(backend_path)
> DjangoObjectBuilder.do_initialize_object(backend, request)
> 
> code
> 


and in another django package we subscribe to this object initialization:


def add_request_to_backend(obj, request):
> obj.request = request
> DjangoObjectBuilder.add_custom_initializer(lambda obj: isinstance(obj, 
> openstack_auth.Backend), add_request_to_backend)




-- 
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/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

Hello Tom
Thank you for your reply
Let me explain the situation again

Openstack auth doesn't use django models at all, it uses keystoneauth 
authorization logic

And this logic requires some data from request to recognize user
https://github.com/openstack/horizon/blob/master/openstack_auth/backend.py#L66

In case of default django function get_user shouldn't have an access to 
request because it uses django model to get a user but in case of openstack 
it's totally different

And unfortunately I see one way - patch django get_user method because we 
need it for django-websocket-redis uwsgi process

https://github.com/jrief/django-websocket-redis/blob/master/ws4redis/wsgi_server.py#L69

Right now the problem is in django-websocket-redis uwsgi process the user 
is always Anonymous because openstack auth is not able to recognize user 
due to the request absence in openstackauthbackend.

About my solution, well, I am happy to accept any ideas, my solution uses 
one of design patterns to solve a problem. Well, the problem is simple: we 
have few different packages which uses one class, but for some specific 
case this class should have an access to another object, for such purposes, 
there's a pattern Builder

https://sourcemaking.com/design_patterns/builder

As I said, I am happy to accept any comments, ideas how to solve it more 
properly

Thank you again for your time.

середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>
> I think Tim’s assessment in the ticket is on point, a DjangoObjectBuilder 
> would look very strange and out of place if included (it’s not particularly 
> pythonic either). 
>
> Seems like there might be a legitimate issue here (or maybe just bad 
> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
> request object rather than monkeypatch Django?
>
>
>

-- 
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/f84a929a-eead-48ae-a6ce-114a3a635320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

But the one thing I don't like is monkey patching. It's ok when you patch 
some whole implementation of something, for example, replace socket 
implementation in gevent with socket implementation in redis.
But when we need to patch something internally in function, that's bad
So, I want just to improve design of django to simplify it in future.
But again, I respect django developers opinion and it's up to you :)

середа, 10 січня 2018 р. 19:00:56 UTC+1 користувач Sergey Glazyrin написав:
>
> Hello Tom
> Thank you for your reply
> Let me explain the situation again
>
> Openstack auth doesn't use django models at all, it uses keystoneauth 
> authorization logic
>
> And this logic requires some data from request to recognize user
>
> https://github.com/openstack/horizon/blob/master/openstack_auth/backend.py#L66
>
> In case of default django function get_user shouldn't have an access to 
> request because it uses django model to get a user but in case of openstack 
> it's totally different
>
> And unfortunately I see one way - patch django get_user method because we 
> need it for django-websocket-redis uwsgi process
>
>
> https://github.com/jrief/django-websocket-redis/blob/master/ws4redis/wsgi_server.py#L69
>
> Right now the problem is in django-websocket-redis uwsgi process the user 
> is always Anonymous because openstack auth is not able to recognize user 
> due to the request absence in openstackauthbackend.
>
> About my solution, well, I am happy to accept any ideas, my solution uses 
> one of design patterns to solve a problem. Well, the problem is simple: we 
> have few different packages which uses one class, but for some specific 
> case this class should have an access to another object, for such purposes, 
> there's a pattern Builder
>
> https://sourcemaking.com/design_patterns/builder
>
> As I said, I am happy to accept any comments, ideas how to solve it more 
> properly
>
> Thank you again for your time.
>
> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>
>> I think Tim’s assessment in the ticket is on point, a DjangoObjectBuilder 
>> would look very strange and out of place if included (it’s not particularly 
>> pythonic either). 
>>
>> Seems like there might be a legitimate issue here (or maybe just bad 
>> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>> request object rather than monkeypatch Django?
>>
>>
>>

-- 
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/5d053a62-1758-4fa2-9766-1eb1c6e6089b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

Btw, I see no way how do I use this auth_user.create_user_from_token to 
solve this problem.
It uses django contrib auth get_user function, so the proper place is to to 
use django auth backend logic.

середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>
> I think Tim’s assessment in the ticket is on point, a DjangoObjectBuilder 
> would look very strange and out of place if included (it’s not particularly 
> pythonic either). 
>
> Seems like there might be a legitimate issue here (or maybe just bad 
> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
> request object rather than monkeypatch Django?
>
> On 10 January 2018 at 12:22:01, Sergey Glazyrin (sergey.gl...@gmail.com 
> ) wrote:
>
> Hello guys! 
> I faced a situation when auth backend needs access to request object 
> inside of get_user auth backend function
>
> https://code.djangoproject.com/ticket/29005
>
> I can patch it following way (function to be patched is 
> django.contrib.auth.get_user)
>
>
> def get_user(request):
>>
>  
>
> ..
>> code
>> .
>>  backend = load_backend(backend_path)
>>  backend,request = request
>> .
>> code
>> .
>
>
>
> But I don't like this solution because I'll need to keep my eyes on this 
> monkey patch while django upgrade, etc, and it's very dirty hack.
>
> Instead I propose to extend django behaviour using design pattern Builder 
> to simplify integration of another apps into django object internals (it 
> sounds hacky, but it's safe and simple to implement)
>
> with change I proposed, the patch would be done on django level, we need 
> to add
>
> def get_user(request):
>>
>> ...
>> code
>> ...
>>
>>  backend = load_backend(backend_path)
>> DjangoObjectBuilder.do_initialize_object(backend, request)
>> 
>> code
>> 
>
>
> and in another django package we subscribe to this object initialization:
>
>
> def add_request_to_backend(obj, request):
>> obj.request = request
>> DjangoObjectBuilder.add_custom_initializer(lambda obj: isinstance(obj, 
>> openstack_auth.Backend), add_request_to_backend)
>
>
>
>
> --
> 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 post to this group, send email to django-d...@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/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/66604e89-236e-4bb2-935b-41b5ab8cc508%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

Yes, that would be a consensus but who knows the future, what if one day 
another django auth backend will need request in another method,
that's why I prefer the idea of implementing it into design pattern 
"Builder" way. It's much more cleaner solution, imho

середа, 10 січня 2018 р. 19:18:28 UTC+1 користувач Tim Graham написав:
>
> Without studying the openstack code much it's hard for me to say if the 
> solution there is the best approach and that a more elegant solution 
> doesn't exist. It looks like if we added 'request' to the signature of the 
> authentication backend get_user() method, that would remove the need for 
> monkey patching. We did a similar change for the authenticate() method [1], 
> I'm not sure if there would be consensus to make the change.
>
> [1] https://code.djangoproject.com/ticket/25187
>
> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin wrote:
>>
>> Btw, I see no way how do I use this auth_user.create_user_from_token to 
>> solve this problem.
>> It uses django contrib auth get_user function, so the proper place is to 
>> to use django auth backend logic.
>>
>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>
>>> I think Tim’s assessment in the ticket is on point, a 
>>> DjangoObjectBuilder would look very strange and out of place if included 
>>> (it’s not particularly pythonic either). 
>>>
>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>>> request object rather than monkeypatch Django?
>>>
>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (sergey.gl...@gmail.com) 
>>> wrote:
>>>
>>> Hello guys! 
>>> I faced a situation when auth backend needs access to request object 
>>> inside of get_user auth backend function
>>>
>>> https://code.djangoproject.com/ticket/29005
>>>
>>> I can patch it following way (function to be patched is 
>>> django.contrib.auth.get_user)
>>>
>>>
>>> def get_user(request):
>>>>
>>>  
>>>
>>> ..
>>>> code
>>>> .
>>>>  backend = load_backend(backend_path)
>>>>  backend,request = request
>>>> .
>>>> code
>>>> .
>>>
>>>
>>>
>>> But I don't like this solution because I'll need to keep my eyes on this 
>>> monkey patch while django upgrade, etc, and it's very dirty hack.
>>>
>>> Instead I propose to extend django behaviour using design pattern 
>>> Builder to simplify integration of another apps into django object 
>>> internals (it sounds hacky, but it's safe and simple to implement)
>>>
>>> with change I proposed, the patch would be done on django level, we need 
>>> to add
>>>
>>> def get_user(request):
>>>>
>>>> ...
>>>> code
>>>> ...
>>>>
>>>>  backend = load_backend(backend_path)
>>>> DjangoObjectBuilder.do_initialize_object(backend, request)
>>>> 
>>>> code
>>>> 
>>>
>>>
>>> and in another django package we subscribe to this object initialization:
>>>
>>>
>>> def add_request_to_backend(obj, request):
>>>> obj.request = request
>>>> DjangoObjectBuilder.add_custom_initializer(lambda obj: isinstance(obj, 
>>>> openstack_auth.Backend), add_request_to_backend)
>>>
>>>
>>>
>>>
>>> --
>>> 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 post to this group, send email to django-d...@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/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>

-- 
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/36c02bfb-fea7-4f29-aef4-546bffc064fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

that would allow another python packages to subscribe to specific parts of 
building django objects and that would be very expandable solution

середа, 10 січня 2018 р. 19:18:28 UTC+1 користувач Tim Graham написав:
>
> Without studying the openstack code much it's hard for me to say if the 
> solution there is the best approach and that a more elegant solution 
> doesn't exist. It looks like if we added 'request' to the signature of the 
> authentication backend get_user() method, that would remove the need for 
> monkey patching. We did a similar change for the authenticate() method [1], 
> I'm not sure if there would be consensus to make the change.
>
> [1] https://code.djangoproject.com/ticket/25187
>
> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin wrote:
>>
>> Btw, I see no way how do I use this auth_user.create_user_from_token to 
>> solve this problem.
>> It uses django contrib auth get_user function, so the proper place is to 
>> to use django auth backend logic.
>>
>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>
>>> I think Tim’s assessment in the ticket is on point, a 
>>> DjangoObjectBuilder would look very strange and out of place if included 
>>> (it’s not particularly pythonic either). 
>>>
>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>>> request object rather than monkeypatch Django?
>>>
>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (sergey.gl...@gmail.com) 
>>> wrote:
>>>
>>> Hello guys! 
>>> I faced a situation when auth backend needs access to request object 
>>> inside of get_user auth backend function
>>>
>>> https://code.djangoproject.com/ticket/29005
>>>
>>> I can patch it following way (function to be patched is 
>>> django.contrib.auth.get_user)
>>>
>>>
>>> def get_user(request):
>>>>
>>>  
>>>
>>> ..
>>>> code
>>>> .
>>>>  backend = load_backend(backend_path)
>>>>  backend,request = request
>>>> .
>>>> code
>>>> .
>>>
>>>
>>>
>>> But I don't like this solution because I'll need to keep my eyes on this 
>>> monkey patch while django upgrade, etc, and it's very dirty hack.
>>>
>>> Instead I propose to extend django behaviour using design pattern 
>>> Builder to simplify integration of another apps into django object 
>>> internals (it sounds hacky, but it's safe and simple to implement)
>>>
>>> with change I proposed, the patch would be done on django level, we need 
>>> to add
>>>
>>> def get_user(request):
>>>>
>>>> ...
>>>> code
>>>> ...
>>>>
>>>>  backend = load_backend(backend_path)
>>>> DjangoObjectBuilder.do_initialize_object(backend, request)
>>>> 
>>>> code
>>>> 
>>>
>>>
>>> and in another django package we subscribe to this object initialization:
>>>
>>>
>>> def add_request_to_backend(obj, request):
>>>> obj.request = request
>>>> DjangoObjectBuilder.add_custom_initializer(lambda obj: isinstance(obj, 
>>>> openstack_auth.Backend), add_request_to_backend)
>>>
>>>
>>>
>>>
>>> --
>>> 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 post to this group, send email to django-d...@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/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/5dffbda9-7239-489e-9530-564df9ab578e%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>

-- 
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/0330b444-af4c-419b-92d1-351bd28d6ffd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

We use function load_backend in django about 5 times in production code, 
so, it shouldn't be a big change
About signals idea: yes, I can implement it using signals abstraction 
though I prefer to be tied to the "Builder" idea, there would no big 
difference between signals and Builder implementation in this case because 
load_backend always returns a new instance of the class, so, I expect no 
threading problems, etc, it's just a way to distribute process of building 
objects
About adding request to get_user, I don't like it because then all 
dependent of django projects will need to change backends, it would be 
worst for community 

середа, 10 січня 2018 р. 19:52:06 UTC+1 користувач Tom Forbes написав:
>
> I would be in favour of a mechanism to help with this use case, I ran into 
> a somewhat similar issue when using JWTs and a non-model backed user. 
>
> Adding a user parameter seems like the easiest solution and quite simple, 
> whereas adding a builder class into this particular section of Django seems 
> like it would be harder to get consensus. 
>
> You could maybe get more traction if you suggested firing a signal that is 
> passed the auth instance as a parameter when it is initialized, which is 
> akin to your suggestion, however IMO that's still not a great idea.
>
> On 10 Jan 2018 18:18, "Tim Graham" > 
> wrote:
>
>> Without studying the openstack code much it's hard for me to say if the 
>> solution there is the best approach and that a more elegant solution 
>> doesn't exist. It looks like if we added 'request' to the signature of the 
>> authentication backend get_user() method, that would remove the need for 
>> monkey patching. We did a similar change for the authenticate() method [1], 
>> I'm not sure if there would be consensus to make the change.
>>
>> [1] https://code.djangoproject.com/ticket/25187
>>
>> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin wrote:
>>>
>>> Btw, I see no way how do I use this auth_user.create_user_from_token to 
>>> solve this problem.
>>> It uses django contrib auth get_user function, so the proper place is to 
>>> to use django auth backend logic.
>>>
>>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>>
>>>> I think Tim’s assessment in the ticket is on point, a 
>>>> DjangoObjectBuilder would look very strange and out of place if included 
>>>> (it’s not particularly pythonic either). 
>>>>
>>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>>> designs in OpenStack?), but unless I’m misunderstanding something couldn’t 
>>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>>>> request object rather than monkeypatch Django?
>>>>
>>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (sergey.gl...@gmail.com) 
>>>> wrote:
>>>>
>>>> Hello guys! 
>>>> I faced a situation when auth backend needs access to request object 
>>>> inside of get_user auth backend function
>>>>
>>>> https://code.djangoproject.com/ticket/29005
>>>>
>>>> I can patch it following way (function to be patched is 
>>>> django.contrib.auth.get_user)
>>>>
>>>>
>>>> def get_user(request):
>>>>>
>>>>  
>>>>
>>>> ..
>>>>> code
>>>>> .
>>>>>  backend = load_backend(backend_path)
>>>>>  backend,request = request
>>>>> .
>>>>> code
>>>>> .
>>>>
>>>>
>>>>
>>>> But I don't like this solution because I'll need to keep my eyes on 
>>>> this monkey patch while django upgrade, etc, and it's very dirty hack.
>>>>
>>>> Instead I propose to extend django behaviour using design pattern 
>>>> Builder to simplify integration of another apps into django object 
>>>> internals (it sounds hacky, but it's safe and simple to implement)
>>>>
>>>> with change I proposed, the patch would be done on django level, we 
>>>> need to add
>>>>
>>>> def get_user(request):
>>>>>
>>>>> ...
>>>>> code
>>>>> ...
>>>>>
>>>>>  backend = load_backend(backend_path)
>>>>> DjangoObjectBuilder.do_initialize_object(backend, request)
>&g

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

ok, let me know if there would be any consensus and I'll change my solution 
according to maintainers consensus.

середа, 10 січня 2018 р. 20:10:46 UTC+1 користувач Tom Forbes написав:
>
> Django has managed this before by examining the function signature. Adding 
> a property directly onto the instance could cause some issues, for example 
> if there is already a user property. I guess this could be detected and a 
> deprecation warning issued though.
>
> Anyway, this is all academic unless there is consensus. 
>
> On 10 Jan 2018 19:00, "Sergey Glazyrin"  > wrote:
>
> We use function load_backend in django about 5 times in production code, 
> so, it shouldn't be a big change
> About signals idea: yes, I can implement it using signals abstraction 
> though I prefer to be tied to the "Builder" idea, there would no big 
> difference between signals and Builder implementation in this case because 
> load_backend always returns a new instance of the class, so, I expect no 
> threading problems, etc, it's just a way to distribute process of building 
> objects
> About adding request to get_user, I don't like it because then all 
> dependent of django projects will need to change backends, it would be 
> worst for community 
>
> середа, 10 січня 2018 р. 19:52:06 UTC+1 користувач Tom Forbes написав:
>>
>> I would be in favour of a mechanism to help with this use case, I ran 
>> into a somewhat similar issue when using JWTs and a non-model backed user. 
>>
>> Adding a user parameter seems like the easiest solution and quite simple, 
>> whereas adding a builder class into this particular section of Django seems 
>> like it would be harder to get consensus. 
>>
>> You could maybe get more traction if you suggested firing a signal that 
>> is passed the auth instance as a parameter when it is initialized, which is 
>> akin to your suggestion, however IMO that's still not a great idea.
>>
>> On 10 Jan 2018 18:18, "Tim Graham"  wrote:
>>
>>> Without studying the openstack code much it's hard for me to say if the 
>>> solution there is the best approach and that a more elegant solution 
>>> doesn't exist. It looks like if we added 'request' to the signature of the 
>>> authentication backend get_user() method, that would remove the need for 
>>> monkey patching. We did a similar change for the authenticate() method [1], 
>>> I'm not sure if there would be consensus to make the change.
>>>
>>> [1] https://code.djangoproject.com/ticket/25187
>>>
>>> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin 
>>> wrote:
>>>>
>>>> Btw, I see no way how do I use this auth_user.create_user_from_token to 
>>>> solve this problem.
>>>> It uses django contrib auth get_user function, so the proper place is 
>>>> to to use django auth backend logic.
>>>>
>>>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>>>
>>>>> I think Tim’s assessment in the ticket is on point, a 
>>>>> DjangoObjectBuilder would look very strange and out of place if included 
>>>>> (it’s not particularly pythonic either). 
>>>>>
>>>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>>>> designs in OpenStack?), but unless I’m misunderstanding something 
>>>>> couldn’t 
>>>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>>>>> request object rather than monkeypatch Django?
>>>>>
>>>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (
>>>>> sergey.gl...@gmail.com) wrote:
>>>>>
>>>>> Hello guys! 
>>>>> I faced a situation when auth backend needs access to request object 
>>>>> inside of get_user auth backend function
>>>>>
>>>>> https://code.djangoproject.com/ticket/29005
>>>>>
>>>>> I can patch it following way (function to be patched is 
>>>>> django.contrib.auth.get_user)
>>>>>
>>>>>
>>>>> def get_user(request):
>>>>>>
>>>>>  
>>>>>
>>>>> ..
>>>>>> code
>>>>>> .
>>>>>>  backend = load_backend(backend_path)
>>>>>>  backend,request = request
>>>>>> .
>>>>>> code
>>>>>> .
&g

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

or we can add a simple builder helper
def build_backend_django_object(class_, request):
obj = class_()
if hasattr(obj, 'request'):
   warnings.warn('Please change your auth backend because now we pass to 
the instance of backend HttpRequest object')
else:
   obj.request = request
return obj

середа, 10 січня 2018 р. 20:13:06 UTC+1 користувач Sergey Glazyrin написав:
>
> ok, let me know if there would be any consensus and I'll change my 
> solution according to maintainers consensus.
>
> середа, 10 січня 2018 р. 20:10:46 UTC+1 користувач Tom Forbes написав:
>>
>> Django has managed this before by examining the function signature. 
>> Adding a property directly onto the instance could cause some issues, for 
>> example if there is already a user property. I guess this could be detected 
>> and a deprecation warning issued though.
>>
>> Anyway, this is all academic unless there is consensus. 
>>
>> On 10 Jan 2018 19:00, "Sergey Glazyrin"  wrote:
>>
>> We use function load_backend in django about 5 times in production code, 
>> so, it shouldn't be a big change
>> About signals idea: yes, I can implement it using signals abstraction 
>> though I prefer to be tied to the "Builder" idea, there would no big 
>> difference between signals and Builder implementation in this case because 
>> load_backend always returns a new instance of the class, so, I expect no 
>> threading problems, etc, it's just a way to distribute process of building 
>> objects
>> About adding request to get_user, I don't like it because then all 
>> dependent of django projects will need to change backends, it would be 
>> worst for community 
>>
>> середа, 10 січня 2018 р. 19:52:06 UTC+1 користувач Tom Forbes написав:
>>>
>>> I would be in favour of a mechanism to help with this use case, I ran 
>>> into a somewhat similar issue when using JWTs and a non-model backed user. 
>>>
>>> Adding a user parameter seems like the easiest solution and quite 
>>> simple, whereas adding a builder class into this particular section of 
>>> Django seems like it would be harder to get consensus. 
>>>
>>> You could maybe get more traction if you suggested firing a signal that 
>>> is passed the auth instance as a parameter when it is initialized, which is 
>>> akin to your suggestion, however IMO that's still not a great idea.
>>>
>>> On 10 Jan 2018 18:18, "Tim Graham"  wrote:
>>>
>>>> Without studying the openstack code much it's hard for me to say if the 
>>>> solution there is the best approach and that a more elegant solution 
>>>> doesn't exist. It looks like if we added 'request' to the signature of the 
>>>> authentication backend get_user() method, that would remove the need for 
>>>> monkey patching. We did a similar change for the authenticate() method 
>>>> [1], 
>>>> I'm not sure if there would be consensus to make the change.
>>>>
>>>> [1] https://code.djangoproject.com/ticket/25187
>>>>
>>>> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin 
>>>> wrote:
>>>>>
>>>>> Btw, I see no way how do I use this auth_user.create_user_from_token 
>>>>> to solve this problem.
>>>>> It uses django contrib auth get_user function, so the proper place is 
>>>>> to to use django auth backend logic.
>>>>>
>>>>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>>>>
>>>>>> I think Tim’s assessment in the ticket is on point, a 
>>>>>> DjangoObjectBuilder would look very strange and out of place if included 
>>>>>> (it’s not particularly pythonic either). 
>>>>>>
>>>>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>>>>> designs in OpenStack?), but unless I’m misunderstanding something 
>>>>>> couldn’t 
>>>>>> you call ‘auth_user.create_user_from_token’ yourself and set it on the 
>>>>>> request object rather than monkeypatch Django?
>>>>>>
>>>>>> On 10 January 2018 at 12:22:01, Sergey Glazyrin (
>>>>>> sergey.gl...@gmail.com) wrote:
>>>>>>
>>>>>> Hello guys! 
>>>>>> I faced a situation when auth backend needs access to request object 
>>>>>> inside of get_user auth ba

Re: ease patching Django object behavior in another django packages

[Sergey Glazyrin]

hello guys!
I added a new changeset to reflect what we discussed here
Please check it out.
https://github.com/django/django/compare/master...sergeyglazyrindev:master

середа, 10 січня 2018 р. 21:02:41 UTC+1 користувач Sergey Glazyrin написав:
>
> or we can add a simple builder helper
> def build_backend_django_object(class_, request):
> obj = class_()
> if hasattr(obj, 'request'):
>warnings.warn('Please change your auth backend because now we pass to 
> the instance of backend HttpRequest object')
> else:
>obj.request = request
> return obj
>
> середа, 10 січня 2018 р. 20:13:06 UTC+1 користувач Sergey Glazyrin написав:
>>
>> ok, let me know if there would be any consensus and I'll change my 
>> solution according to maintainers consensus.
>>
>> середа, 10 січня 2018 р. 20:10:46 UTC+1 користувач Tom Forbes написав:
>>>
>>> Django has managed this before by examining the function signature. 
>>> Adding a property directly onto the instance could cause some issues, for 
>>> example if there is already a user property. I guess this could be detected 
>>> and a deprecation warning issued though.
>>>
>>> Anyway, this is all academic unless there is consensus. 
>>>
>>> On 10 Jan 2018 19:00, "Sergey Glazyrin"  wrote:
>>>
>>> We use function load_backend in django about 5 times in production code, 
>>> so, it shouldn't be a big change
>>> About signals idea: yes, I can implement it using signals abstraction 
>>> though I prefer to be tied to the "Builder" idea, there would no big 
>>> difference between signals and Builder implementation in this case because 
>>> load_backend always returns a new instance of the class, so, I expect no 
>>> threading problems, etc, it's just a way to distribute process of building 
>>> objects
>>> About adding request to get_user, I don't like it because then all 
>>> dependent of django projects will need to change backends, it would be 
>>> worst for community 
>>>
>>> середа, 10 січня 2018 р. 19:52:06 UTC+1 користувач Tom Forbes написав:
>>>>
>>>> I would be in favour of a mechanism to help with this use case, I ran 
>>>> into a somewhat similar issue when using JWTs and a non-model backed user. 
>>>>
>>>> Adding a user parameter seems like the easiest solution and quite 
>>>> simple, whereas adding a builder class into this particular section of 
>>>> Django seems like it would be harder to get consensus. 
>>>>
>>>> You could maybe get more traction if you suggested firing a signal that 
>>>> is passed the auth instance as a parameter when it is initialized, which 
>>>> is 
>>>> akin to your suggestion, however IMO that's still not a great idea.
>>>>
>>>> On 10 Jan 2018 18:18, "Tim Graham"  wrote:
>>>>
>>>>> Without studying the openstack code much it's hard for me to say if 
>>>>> the solution there is the best approach and that a more elegant solution 
>>>>> doesn't exist. It looks like if we added 'request' to the signature of 
>>>>> the 
>>>>> authentication backend get_user() method, that would remove the need for 
>>>>> monkey patching. We did a similar change for the authenticate() method 
>>>>> [1], 
>>>>> I'm not sure if there would be consensus to make the change.
>>>>>
>>>>> [1] https://code.djangoproject.com/ticket/25187
>>>>>
>>>>> On Wednesday, January 10, 2018 at 1:12:55 PM UTC-5, Sergey Glazyrin 
>>>>> wrote:
>>>>>>
>>>>>> Btw, I see no way how do I use this auth_user.create_user_from_token 
>>>>>> to solve this problem.
>>>>>> It uses django contrib auth get_user function, so the proper place is 
>>>>>> to to use django auth backend logic.
>>>>>>
>>>>>> середа, 10 січня 2018 р. 14:17:50 UTC+1 користувач Tom Forbes написав:
>>>>>>>
>>>>>>> I think Tim’s assessment in the ticket is on point, a 
>>>>>>> DjangoObjectBuilder would look very strange and out of place if 
>>>>>>> included 
>>>>>>> (it’s not particularly pythonic either). 
>>>>>>>
>>>>>>> Seems like there might be a legitimate issue here (or maybe just bad 
>>>>>>> des

Re: PostgreSQL Partial Indexes package

[Sergey Fursov]

Hi everyone,

In our company, we also use the ability to define our own indexes, but with
the current implementation of base Index class, we basically need to copy
several methods entirely from it.
What do we want is implement UNIQUE indexes with the UPPER function wrapper
around field names [1].
This provides two benefits to us:
1) case-insensitive uniqueness of the field or the fields combination
2) quick filtering using iexact lookup, which uses UPPER() LIKE
 statement in SQL (at least for the Postgres)

I think, adding more flexibility in current indexes build logic would help
to implement and further support custom indexes implementations (like
django-partial-index )
if we are not going to merge them in Django core or contrib.

[1] https://gist.github.com/GeyseR/363b4b9d2d1cd8c91d51ebfe9369a7ac


пт, 20 окт. 2017 г. в 14:37, Ashley Waite :

> I did a similar thing (but only tested in postgres) a while back, using
> Q's / filter clause to generate the where clause.
>
> Perhaps with our powers combined we're close to a generalised
> implementation?
>
>
> https://github.com/ashleywaite/django-more/blob/master/django_more/indexes.py
>
>
>
> On Saturday, October 7, 2017 at 7:56:00 PM UTC+11, Mattias Linnap wrote:
>>
>> Hi django-developers,
>>
>> I have written a package that implements PostgreSQL and SQLite partial
>> indexes on top of the new class-based indexes:
>> https://github.com/mattiaslinnap/django-partial-index
>> The most common use case is partial unique constraints, but I have a few
>> projects where non-unique partial indexes have turned out useful as well.
>>
>> I have a few questions on how to continue with this:
>>
>> 1. Right now the "where condition" expression is provided as a string,
>> and has to be different for PostgreSQL and SQLite in some common cases (for
>> example boolean literals). Is there a good abstraction for SQL expressions
>> somewhere in Django internals that I could use instead, something similar
>> to Q-expressions perhaps? In particular, to add validate_unique() support
>> to ModelForms, I would need to be able to extract all fields that are
>> mentioned in the where condition.
>> 2. I've seen mentions of a "check constraints" support being in
>> development (https://github.com/django/django/pull/7615). Will that
>> include partial unique constraints, or is just for the per-column checks?
>> 3. If separate, then it would be nice to one day get partial indexes
>> merged into the contrib.postgres package. Do you have any suggestions on
>> what needs to happen before that - more test coverage, more contributors,
>> more users, or similar?
>>
>> Best,
>>
>> Mattias
>>
> --
> 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/84f4431a-cdab-43c7-b96b-de4d2eb9805b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAG-zk-CJnbuQASEmey6%2BWEewVrn8TPhxpUfv8TfzQEakAgwM%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

proposal: add special subclass of ForeignKey for storing ContentTypes

[Sergey Fedoseev]

Hi all,

Some time ago I created 'new feature` ticket 
 and Tim Graham asked me to 
write here to get some feedback on the idea. So here it is.

ContentType model is quite specific, so we could add the subclass of 
ForeignKey with some specific features.


For example, we have a model:


class ModelWithContentType(models.Model):
ct = ContentTypeField(on_delete=models.CASCADE)
 

In comparison with ForeignKey ContentTypeField will have these features:

   1. ModelWithContentType.objects.first().ct will use content types cache 


   1. ContentTypeField will support lookups on the model classes (on model 
   instances too?):

ModelWithContentType.objects.filter(ct=FooModel) vs.

ModelWithContentType.objects.filter(ct=ContentType.objects.get_for_model(FooModel))


ModelWithContentType.objects.filter(ct__in=[FooModel, BarModel]) vs.
ModelWithContentType.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
 
in [FooModel, BarModel]])

   1. Creation using a model class as a value (not sure if it's useful 
   actually): 

ModelWithContentType.objects.create(ct=FooModel)


Here's ​rough implementation 
.

-- 
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/7a1bcdcf-bd6c-4258-b0dc-a98492493a53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

[Sergey Fursov]

Hi everyone,

I just want to mention here that in django-jsonfield repo proposed solution
to solve this problem on third party side:
https://github.com/dmkoch/django-jsonfield/issues/189. Maybe this is the
better way.

Thanks,
Sergey

2017-06-03 0:02 GMT+03:00 Zack Voase :

> Hi all,
>
> I'm encountering exceptions in a number of popular third-party Django
> libraries when upgrading from 1.8 to 1.11. The code path is typically
> `MyModel.objects.get_or_create(...)`, which causes
> `model._meta._property_names` to be checked (to make sure we're not
> querying/setting a property). The problem is, `_property_names` is
> implemented as follows:
>
> # in django/db/models/options.py:
> def _property_names(self):
> return frozenset({
>attr for attr in
>dir(self.model) if isinstance(getattr(self.model, attr), property)
> })
>
> The problem is when a custom field installs a field descriptor on the
> model class (during `contribute_to_class()`), with a `__get__()` method
> like this:
>
> class SomeFieldDescriptor(object):
> # ...
> def __get__(self, instance, type=None):
> if instance is None:
> raise AttributeError("Can only be accessed via an instance.")
> # ...
>
> Libraries which install such descriptors include [django-fsm](
> https://github.com/kmmbvnr/django-fsm/blob/2d2eaee/django_fsm/__init__.
> py#L225) and [django-jsonfield](https://github.com/dmkoch/django-
> jsonfield/blob/2.0.1/jsonfield/subclassing.py#L35). I think the problem
> is that we can't assume that all results of `dir(model_class)` can be
> accessed via `getattr(model_class, attr)` without exception; indeed, the
> Python docs state (c.f. https://docs.python.org/2/
> library/functions.html#dir):
>
> > Because dir() is supplied primarily as a convenience for use at an
> interactive prompt, it tries to supply an interesting set of names more
> than it tries to supply a rigorously or consistently defined set of names,
> and its detailed behavior may change across releases.
>
> A potential fix would be to adjust the definition of `_property_names`
> like so:
>
> def _property_names(self):
> attrs = []
> for attr in dir(self.model):
> try:
> if isinstance(getattr(self.model, attr), property):
> attrs.append(attr)
> except AttributeError:
> pass
> return frozenset(attrs)
>
> Does this seem like a good solution, or even a problem worth solving?
>
> Thanks!
> -- Zack
>
> --
> 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/ec0e2506-4c4b-441f-b005-
> 5623d6521ae3%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ec0e2506-4c4b-441f-b005-5623d6521ae3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAG-zk-BDvJOQfhgNBFBpRCBuPkB7MTtJCYLp6D1jxgbppMdr%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Signal-based cache invalidation & cached function decorator

[Sergey Kirillov]

Hi all

In my project I frequently encountered a situation where I need to
cache some data, and then invalidate it on signal.

So I wrote following decorator:

def cached(slot_name, timeout=None):
def decorator(function):
def invalidate():
cache.delete(slot_name)

def wrapped(*args, **kwargs):
result = cache.get(slot_name)
if result is None:
result = function(*args, **kwargs)
cache.set(slot_name, result, timeout)
return result
wrapped.invalidate = invalidate
return wrapped
return decorator




And here is example usage:

@cached('/data/something_hard')
def get_something_hard():

return result

dispatcher.connect(get_something_hard.invalidate,
django.db.models.signals.post_save, Model)


I think it's generic enough and can be included in Django itself.

What do you think?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal-based cache invalidation & cached function decorator

[Sergey Kirillov]

For shared cache backends, like Memcached it works fine. You just need
to be sure that signal handlers will be registered in all processes
(i.e. put them in models.py)

On Nov 14, 4:20 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 2:41 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Hi all
>
> > In my project I frequently encountered a situation where I need to
> > cache some data, and then invalidate it on signal.
>
> > So I wrote following decorator:
>
> > def cached(slot_name, timeout=None):
> > def decorator(function):
> > def invalidate():
> > cache.delete(slot_name)
>
> > def wrapped(*args, **kwargs):
> > result = cache.get(slot_name)
> > if result is None:
> > result = function(*args, **kwargs)
> > cache.set(slot_name, result, timeout)
> > return result
> > wrapped.invalidate = invalidate
> > return wrapped
> > return decorator
>
> > And here is example usage:
>
> > @cached('/data/something_hard')
> > def get_something_hard():
> > 
> > return result
>
> > dispatcher.connect(get_something_hard.invalidate,
> > django.db.models.signals.post_save, Model)
>
> > I think it's generic enough and can be included in Django itself.
>
> > What do you think?
>
> this wouldn't work across more boxes and/or processes - one process
> creates the cache and registers the signal, another process changes
> the object and fires the signal, which isn't trapped.
>
>
>
> --
> Honza Kr?l
> E-Mail: [EMAIL PROTECTED]
> ICQ#:   107471613
> Phone:  +420 606 678585


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal-based cache invalidation & cached function decorator

[Sergey Kirillov]

That's true.

So, does it looks interesting for someone?

Or I'm the only one who do signal-based cache invalidation? :)



On Nov 15, 2:27 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 9:13 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
>
>
> > For shared cache backends, like Memcached it works fine. You just need
> > to be sure that signal handlers will be registered in all processes
> > (i.e. put them in models.py)
>
> sorry, my bad - we do a similar thing but dynamic, and that where this
> problem occurs, when the binding to a signal is static, its not an
> issue
>
>
>
>
>
> > On Nov 14, 4:20 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
>
> > > On Nov 14, 2007 2:41 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
> > > > Hi all
>
> > > > In my project I frequently encountered a situation where I need to
> > > > cache some data, and then invalidate it on signal.
>
> > > > So I wrote following decorator:
>
> > > > def cached(slot_name, timeout=None):
> > > > def decorator(function):
> > > > def invalidate():
> > > > cache.delete(slot_name)
>
> > > > def wrapped(*args, **kwargs):
> > > > result = cache.get(slot_name)
> > > > if result is None:
> > > > result = function(*args, **kwargs)
> > > > cache.set(slot_name, result, timeout)
> > > > return result
> > > > wrapped.invalidate = invalidate
> > > > return wrapped
> > > > return decorator
>
> > > > And here is example usage:
>
> > > > @cached('/data/something_hard')
> > > > def get_something_hard():
> > > > 
> > > > return result
>
> > > > dispatcher.connect(get_something_hard.invalidate,
> > > > django.db.models.signals.post_save, Model)
>
> > > > I think it's generic enough and can be included in Django itself.
>
> > > > What do you think?
>
> > > this wouldn't work across more boxes and/or processes - one process
> > > creates the cache and registers the signal, another process changes
> > > the object and fires the signal, which isn't trapped.
>
> > > --
> > > Honza Kr?l
> > > E-Mail: [EMAIL PROTECTED]
> > > ICQ#:   107471613
> > > Phone:  +420 606 678585
>
> --
> Honza Král
> E-Mail: [EMAIL PROTECTED]
> ICQ#:   107471613
> Phone:  +420 606 678585
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---