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
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
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
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
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
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
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.
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
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
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.
10 matches
Mail list logo