Hi,
I'm a long term Django user but have never contributed to the main
Django code base mainly because I haven't really needed any extra
features. Until now.
I only use PostgreSQL as my database and the recent addition of
django.contrib.postgresql got me thinking about other features of
Pos
On 15/04/15 23:45, Kevin Christopher Henry wrote:
This issue was the subject of https://code.djangoproject.com/ticket/24082.
There, the accepted (but not implemented) solution is the same as
suggested here: allowing the user to opt out of the creation of the
additional index with `db_index=False
On 15/04/15 18:22, Tim Graham wrote:
#19441 is the ticket where it was decided that unique=True implies a
database index. The documentation says,
"Note that when ``unique`` is ``True``, you don't need to specify
`Field.db_index`, because ``unique`` implies the creation of an index."
Understo
On 15/04/15 03:37, Curtis Maloney wrote:
Was the OP referring to the unique index, or the index created for the
LIKE lookups?
I was involved in a discussion recently [was there something on list
too?] wanting to be able to opt-out of the second index because they
knew they didn't need it, and it
Using Django 1.8, psycopg2 2.6 and PostgreSQL 9.4.1.
I have a model with a models.TextField(unique=True, db_index=False,
primary_key=False) field in it.
I understand that an index is created because of the comment shown in
this code:
https://github.com/django/django/blob/master/django/db/ba
On 14/01/15 01:06, Jannis Leidel wrote:
On 14 Jan 2015, at 01:24, Some Developer wrote:
On 13/01/15 19:48, patrick91 wrote:
I cannot see any of these on my mac, I'll see if I have any linux
machine where I can see if I can reproduce.
Meanwhile, can you tell us if you have the same s
On 13/01/15 19:48, patrick91 wrote:
I cannot see any of these on my mac, I'll see if I have any linux
machine where I can see if I can reproduce.
Meanwhile, can you tell us if you have the same styles for the code
tags? https://up.kibakoapp.com/AaFwwhccdE
Also try to play with font-family. Mayb
On 13/01/15 20:11, Raphael Michel wrote:
Am Tue, 13 Jan 2015 20:36:45 +0100
schrieb Aymeric Augustin :
Well, there are 10k subscribers to this list. Who else is seing this?
I don't, and I run pretty much the same configuration (Chrome on Arch
Linux on multiple computers). I think it pretty obv
On 13/01/15 23:10, Jannis Leidel wrote:
I just deployed a potential fix, can you try again?
Jannis
Same issue I'm afraid.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group
I know this isn't strictly speaking a Django dev topic but since the
developers are the ones who changed the Django documentation theme /
appearance they should probably be made aware of the problem.
http://imgur.com/FtEpcdy
http://imgur.com/1ON8xxs
http://imgur.com/C6G0DfI
Above are some scre
On 15/11/14 15:33, Aymeric Augustin wrote:
Hello,
The Django team has been discussing the timeline for dropping
support for older Python versions. The current consensus is:
- Support Python 2.x until the LTS version after 1.8, which should
be released late 2017 or early 2018 and supported un
On 25/08/2013 11:25, Aymeric Augustin wrote:
On 18 mai 2013, at 14:07, Erik Romijn wrote:
As far as I know, IPAddressField has no current features that are not also
available in a GenericIPAddressField. Therefore, I suggest that we, some time
from now, deprecate IPAddressField, in favour of
On 14/08/13 10:05, Marc Tamlyn wrote:
(Disclaimer: I didn't write any of this code, I'm just working from my
own possibly flawed understanding)
The main point of using F is not generally for performance per se,
rather for database consistency. In the first example, the performance
increase is ne
On 23/07/13 02:07, Curtis Maloney wrote:
Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]
So, if you feel like helping out with django-fastcgi ... I'm happy fo
On 22/07/13 10:00, Russell Keith-Magee wrote:
The hope is to start accelerating the release cycle slightly; however,
this also depends on someone actually doing the work :-)
Sounds good. I'd love to start helping with Django myself but I feel a
bit lost when it comes to useful things to do. Ma
On 22/07/13 05:47, Russell Keith-Magee wrote:
Based on the feedback from this thread (and the fact that multiple core
devs, including a BDFL have weighed in), I think it's safe to say that
the decision has been made. The only question at this point is how long
it takes before someone commits the
On 14/07/13 20:17, Florian Apolloner wrote:
Hi,
I'd like to get rid of everything FCGI-specific in Django sooner or
later (rather sooner). Flup isn't maintained since a long time and there
is no ticket tracker to report stuff. Graham pointed out that if someone
wants to use FCGI they can use
htt
On 21/07/2013 05:08, Curtis Maloney wrote:
I wasn't aware there was a particular performance issue, but I'll
certainly keep it in mind.
Take a look at this:
http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi
I've probably already said it but if you want some help with this
project I'd be
On 20/07/2013 14:02, Curtis Maloney wrote:
I'm more or less building atop flup as it is, however I plan to shed
anything not related to FastCGI.
For me it's a chance to get down and dirty with raw protocols again... I
do agree there is a shorter path to just applying Django's "fixes" to a
fork o
On 20/07/13 13:24, Christian Schmitt wrote:
No FastCGI isn't a bad protocol. But it's not recommand to deploy Python
Application's with FastCGI. FastCGI is good for deploying PHP or even
sometimes Golang (but here, the plain Webserver is better).
But! FastCGI is a low level protocol and WSGI trie
On 20/07/13 12:32, Christian Schmitt wrote:
I would recommand to remove FastCGI.
That's the thing i love with the Python Community. Remove depracted or
obsolete things.
The thing is, there are way more important things to do, than supporting
a 'depracted' way to deploy. And it's really not that
On 19/07/13 01:31, Curtis Maloney wrote:
For those who are keen to keep support for FastCGI, would you be
interested in helping me develop/maintain a Pure Python
FastCGI->WSGI(Django-specific) publisher package?
I agree it's valuable to have, as many have said [and I believe all have
agreed] but
On 15/07/2013 13:37, Florian Apolloner wrote:
On Monday, July 15, 2013 9:38:33 AM UTC+2, Some Developer wrote:
This would be a mistake in my opinion.
Based on what? Django would still support FCGI via flup like it does
now, we'd just get rid of the management commands you usually
On 15/07/13 16:10, Florian Apolloner wrote:
On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
If you're suggesting to move the FastCGI code into a separate app: +1
I'd have just dropped it, but yes we can move it out; although someone
else will have to step up to continue mai
On 15/07/13 13:13, mjl Martin J. Laubach wrote:
Is there actually a problem with flup? Not being maintained doesn't
mean it's totally broken and it obviously works just fine for a lot of
folks?
mjl
I use it myself and haven't had any issues with it either I was just
responding to
On 14/07/13 20:17, Florian Apolloner wrote:
Hi,
I'd like to get rid of everything FCGI-specific in Django sooner or
later (rather sooner). Flup isn't maintained since a long time and there
is no ticket tracker to report stuff. Graham pointed out that if someone
wants to use FCGI they can use
htt
26 matches
Mail list logo
