Re: Implicit ForeignKey index and unique_together

[Cristiano Coelho]

I think that the issue on Trac is actually something different, it talks 
about the need (or not) of an index, when defining a unique constraint. 
Most databases (if not all) will create an index automatically when a 
unique constraint is defined, and correct me if I'm wrong, but PostgreSQL 
(I don't about Oracle) is the only one that actually has constraints 
(unique ones included here) and indexes as a separate thing, but for 
SQLServer and MySQL the unique constraint is just an additional option of 
the index.

What Dilyan is talking about, and correct me if I'm wrong again, is about 
the redundancy of defining an index on a foreing key, if you already have 
that column as the left-most part of an index (unique or not). Most of the 
time it will be redundant to have an index A, and another one (A,B), since 
the latter will be also used for A queries. However this is up to debate 
since using the (A,B) index can be potentially slower than using just the A 
index due to the index being bigger, but you save space and 
insert/update/delete performance for not having two different indexes.

In my case, most of the time I end up with a db_index=False on foreing keys 
that I know I have a index/unique defined somewhere else to avoid the 
overhead of the additional index.

El viernes, 16 de septiembre de 2016, 11:34:52 (UTC-3), Tim Graham escribió:
>
> Did you try to find anything related in Trac? Maybe 
> https://code.djangoproject.com/ticket/24082?
>
> I use this query in Google: postgresql unique index site:
> code.djangoproject.com
>
> On Friday, September 16, 2016 at 9:51:13 AM UTC-4, Dilyan Palauzov wrote:
>>
>> Hello, 
>>
>> according to the documentation models.ForeignKeys creates implicitly an 
>> index on the underlying database. 
>>
>> Wouldn't it be reasonable to change the default behaviour to only create 
>> implicit index, if there is no index_together or unique_together starting 
>> with the name of the foreign key?   In such cases the implicit index is 
>> redundant, at least with Postgresql, as the value can be found fast using 
>> the _together index. 
>>
>> Greetings 
>>Dilian 
>>
>

-- 
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/3200c618-5665-4c9e-8255-ef34da22aef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Marten Kenbeek]

I actually do have working code[1] that among other things abstracts the 
regex to a Constraint, which allows you to easily inject your own custom 
logic for resolving and reversing url fragments. This allows for a "simple" 
system at a more fundamental level, rather than just translating the 
"simple" system to a regex-based system. It has full support for routing on 
any property of the request. The code is mostly in a finished state, and 
the public API is fully backwards compatible, though there are a few small 
changes in Django's current master that'll have to be merged manually or 
rewritten. The biggest hurdle is that it still doesn't have any 
documentation.

I'm afraid I don't have the time to finish it by myself at the moment, as 
I'm juggling work, a new bachelor (computer science!) and other activities. 
I'd like to continue and finish my work when I have the time (and 
motivation), but if someone were to step in where I left off, I'd be happy 
to provide any assistance required. 

[1] https://github.com/knbk/django/tree/dispatcher_api

On Friday, September 16, 2016 at 7:49:45 AM UTC+2, Marc Tamlyn wrote:
>
> Fwiw, I spent a little time investigating this a couple of years ago. I 
> would like to see Django officially bless the idea of alternative URL 
> systems, and provide the "full" regex system and preferably at least one 
> "simple" system - even if all that system supports is integers and slugs. 
> This would allow third party authors to focus on designing their "to regex" 
> translation, rather than the details of Django's resolving.
>
> I did some investigation into swapping at a "deeper" level, including 
> allowing mixed includes from one resolver type to another. This is made 
> somewhat harder by the removal of "patterns", and was much more complex. 
> However it did give much more flexibility in allowing URL patterns which 
> route based on other attributes than the path. I dont have any working 
> code, it was very conceptual. I think we should at least consider a more 
> dramatic approach in a DEP, even if it is not the intended course.
>
> Marc
>
> On 15 Sep 2016 9:52 a.m., "Sjoerd Job Postmus"  > wrote:
>
>>
>>
>> On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha 
>> wrote:
>>>
>>>
>>> As cool as this idea sounds, I really don't think the URL dispatcher 
>>> is a correct component to make database queries. FWIW, I've seen 
>>> similar magic implemented in view decorators, and the thing I remember 
>>> the most from this experience was that it made it a lot harder to 
>>> follow what was happening where. 
>>>
>>> Moreover, I can imagine this turning into a complicated mess of a 
>>> syntax to allow query customizations using a weird DSL really quickly. 
>>> After all, if we allow PK lookups, it's not that unreasonable to also 
>>> want to be able to lookup by other keys, and it all goes downhill from 
>>> here. 
>>>
>>> Cheers, 
>>>
>>> Michal 
>>>
>>
>>
>> Agreed. It all goes downhill from there, so let's at least not do 
>> database queries.
>>
>> To me, that settles it: no typecasting.
>>
>> -- 
>> 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/d9db908b-d22b-428f-908a-ecdc34b8fbfb%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/1a27fb53-269b-491c-b9e1-922b6a7a44b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Implicit ForeignKey index and unique_together

[Tim Graham]

Did you try to find anything related in Trac? Maybe 
https://code.djangoproject.com/ticket/24082?

I use this query in Google: postgresql unique index 
site:code.djangoproject.com

On Friday, September 16, 2016 at 9:51:13 AM UTC-4, Dilyan Palauzov wrote:
>
> Hello, 
>
> according to the documentation models.ForeignKeys creates implicitly an 
> index on the underlying database. 
>
> Wouldn't it be reasonable to change the default behaviour to only create 
> implicit index, if there is no index_together or unique_together starting 
> with the name of the foreign key?   In such cases the implicit index is 
> redundant, at least with Postgresql, as the value can be found fast using 
> the _together index. 
>
> Greetings 
>Dilian 
>

-- 
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/53e1efb0-381a-40ca-874f-763d9f09e8d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trac spam attack / spam filter reactivated

[Uri Even-Chen]

Many messages of the Django developers and Django users mailing lists are
sent into my spam folder in Gmail, and I saw messages from other users who
experience the same problem. I can't filter these messages not to be sent
to spam because I want them to skip my inbox, and Gmail doesn't allow to
skip inbox for messages filtered never to be spam. So every day I have to
search my spam folder and mark these messages as not spam. Then go to my
inbox and archive them.

Any solution?


*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700
Email: u...@speedy.net
Website: http://www.speedysoftware.com/uri/en/
  
    

On Thu, Jul 7, 2016 at 5:33 AM, Tim Graham  wrote:

> In the past couple hours, code.djangoproject.com experienced a spam
> attack of new tickets and wiki pages. After running without the spam filter
> for at least a couple months (I forget exactly when I deactivated it but it
> was sometime after we switched to requiring authenticated users to file a
> ticket), I've reactivated it. If you find your submissions inappropriately
> marked as spam, let me know so we can tune the settings.
>
> --
> 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/ed1a6eb5-122a-4abe-a064-
> 68b3adb0434d%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/CAMQ2MsHFct7mVJoUBOVTBJ4BBPjSs9NF%3DTRf2jjhSk1iiPkwwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Emil Stenström]

On 2016-09-16 09:30, Curtis Maloney wrote:

On 15/09/16 16:37, Curtis Maloney wrote:

Somewhere I have code to provide a "parse" based URL router.

Will dig it up now 1.10 has has shipped


Ah, found it...

So, here is a gist of a sample of using parse
(https://pypi.org/project/parse/) instead of regex.

https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b

Since you can register extra type names, and those types can cast also,
it covers a lot of things some people expect [but don't get] from regex.


This look great, thanks for sharing!

Would love to see casting like this included in Sjoerds library.

/Emil

--
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/29c4afc5-5969-a7ad-ed39-73e08b991d88%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Implicit ForeignKey index and unique_together

[Dilyan Palauzov]

Hello,

according to the documentation models.ForeignKeys creates implicitly an index 
on the underlying database.

Wouldn't it be reasonable to change the default behaviour to only create 
implicit index, if there is no index_together or unique_together starting with 
the name of the foreign key?   In such cases the implicit index is redundant, 
at least with Postgresql, as the value can be found fast using the _together 
index.

Greetings
  Dilian

--
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/d3ca65cc-5146-15ca-a54d-e08cf0b98cd4%40aegee.org.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Chris Foresman]

I'd really, really like an alternate URL resolver which does typecasting. I 
mean, if I'm specifying the type right there, why not expect the resolved 
to be the type I just specified? In 995 of URLs, you're talking about three 
basic types anyway: strings, integers, and (increasingly) UUIDs. After 5 
years it still trips me up when I do a comparison with a number grabbed 
from a URL and, say, Object.otherobject_id.


On Thursday, September 15, 2016 at 3:52:46 AM UTC-5, Sjoerd Job Postmus 
wrote:
>
>
>
> To me, that settles it: no typecasting.
>

-- 
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/0032720b-b1a7-4050-88f3-4fef45027d46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[ludovic coues]

In my opinion, there is two point. First, core django should allow
different url resolver. Second, these different url resolver should
start as third party package.

Without first point, people need to hack django if they want to
experiment new kind of resolver. Like one providing typecasting or a
faster one or a localized one. And the resolver isn't "loosely
coupled" unlike most of the other part of django.

For the second point, I have a simple reason. Choosing between the
rail or the werkzeug syntax is bike shedding. It is not a technically
choice. It's an aesthetic one. There is no right answer, only lost
time.


2016-09-16 9:30 GMT+02:00 Curtis Maloney :
> On 15/09/16 16:37, Curtis Maloney wrote:
>>
>> Somewhere I have code to provide a "parse" based URL router.
>>
>> Will dig it up now 1.10 has has shipped
>
>
> Ah, found it...
>
> So, here is a gist of a sample of using parse
> (https://pypi.org/project/parse/) instead of regex.
>
> https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b
>
> Since you can register extra type names, and those types can cast also, it
> covers a lot of things some people expect [but don't get] from regex.
>
>
> --
> C
>
>
>>
>> On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
>>  wrote:
>>
>> Hi Emil,
>>
>> On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
>> wrote:
>>
>> and more experienced users are expected to switch over to using
>> regexes directly to get the exact behavior they want.
>>
>>
>> How so? Personally I would use this quite quickly since a few
>> builtin types would cover 99%. While I can write regex in sleep
>> nowadays, I still find it kinda tedious to redefine what "slug"
>> means in every URL I wanna match something… I am sure others think
>> the same.
>>
>>
>> Beginners likely won't look at all the different options and
>> choose one based on it's merits, they'll pick whatever their
>> teacher suggests they use. Also installing an extra package when
>> setting up django feels a bit strange.
>>
>>
>> I think the eco system is far enough to support that, after all
>> south lived long and well as external package. Either way, DEP or
>> not, having an implementation out there would definitely help.
>>
>> Cheers,
>> Florian
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> --
>> 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/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net
>>
>> .
>> 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/9ab6342b-f969-4a3b-1263-aabd27cc0eb9%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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/CAEuG%2BTbNnXrd-aAOT_sYbk%2B6_9FB6FYGOFX-g4-oqpfSpQ7Dsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Looking for feedback on implementation of UserManager.with_perm()

[Nick Pope]

Hi Berker,

I just wanted to highlight my comment on the PR here for the benefit of 
those discussing this:

https://github.com/django/django/pull/7153#issuecomment-242672721

We currently horribly abuse the existing permission system to add 
additional global permissions in a hacky way by manually adding content 
types. (https://code.djangoproject.com/ticket/24754 would be awesome) 

My scenario is simply having an easy method to find users *and* groups with 
a particular permission or set of permissions. Doing so is rather clunky at 
the moment.
I also feel that any solution should have the ability to optionally 
include/exclude by is_superuser and is_active flags - we often want to know 
who has a permission whether implicit or explicit.

Thanks,

Nick

On Wednesday, 14 September 2016 05:10:41 UTC+1, Berker Peksag wrote:
>
> https://github.com/django/django/pull/7153/ implements 
> UserManager.with_perm() [1] as: 
>
> def with_perm(self, perm): 
> for backend in auth.get_backends(): 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> [1] "Shortcut to get users by permission": 
> https://code.djangoproject.com/ticket/18763 
>
> With this implementation, users of UserManager.with_perm() won't get 
> users with permissions for all backends. Also, result of 
> UserManager.with_perm() will depend on the order of 
> settings.AUTHENTICATION_BACKENDS. See also 
> https://code.djangoproject.com/ticket/18763#comment:9 for more 
> information about the current strategy. 
>
> I suggested an alternative approach at 
> https://github.com/django/django/pull/7153/files#r78226234 with the 
> following implementation: 
>
> def with_perm(self, perm, backend=None): 
> if backend is None: 
> backends = _get_backends(return_tuples=True) 
> if len(backends) != 1: 
> raise ValueError( 
> 'You have multiple authentication backends configured 
> and ' 
> 'therefore must provide the `backend` argument.' 
> ) 
> _, backend = backends[0] 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> else: 
> backend = load_backend(backend) 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> This also simulates what django.contrib.auth.login() does when 
> multiple authentication backends are defined: 
>
>
> https://github.com/django/django/blob/18c72d59e0807dae75ac2c34890d08c1e0972d0a/django/contrib/auth/__init__.py#L100
>  
>
> Tim suggested to get some feedback about possible use cases: 
>
> "I'm not sure about the use cases. For example, someone might want to 
> get users with permissions for all backends. It would be nice if we 
> had some feedback about what users are implementing on their own to 
> confirm we're targeting the largest use case." 
>
> Is there any other possible use cases? Which one of the suggested 
> approaches cover the largest use case? 
>
> Thanks! 
>
> --Berker 
>

-- 
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/c5249500-d576-44ab-b38a-78ac22866782%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Curtis Maloney]

On 15/09/16 16:37, Curtis Maloney wrote:

Somewhere I have code to provide a "parse" based URL router.

Will dig it up now 1.10 has has shipped


Ah, found it...

So, here is a gist of a sample of using parse 
(https://pypi.org/project/parse/) instead of regex.


https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b

Since you can register extra type names, and those types can cast also, 
it covers a lot of things some people expect [but don't get] from regex.



--
C




On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
 wrote:

Hi Emil,

On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
wrote:

and more experienced users are expected to switch over to using
regexes directly to get the exact behavior they want.


How so? Personally I would use this quite quickly since a few
builtin types would cover 99%. While I can write regex in sleep
nowadays, I still find it kinda tedious to redefine what "slug"
means in every URL I wanna match something… I am sure others think
the same.


Beginners likely won't look at all the different options and
choose one based on it's merits, they'll pick whatever their
teacher suggests they use. Also installing an extra package when
setting up django feels a bit strange.


I think the eco system is far enough to support that, after all
south lived long and well as external package. Either way, DEP or
not, having an implementation out there would definitely help.

Cheers,
Florian


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
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/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net
.
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/9ab6342b-f969-4a3b-1263-aabd27cc0eb9%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.