Ok, I'll wait for other contributors to react.
On Sep 22, 2015 2:03 AM, "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:
> On 22 sept. 2015, at 07:57, Podrigal, Aron
> wrote:
>
> We will be using max_length=255 or 128 for the default as Shia proposed.
>
> Would you mind giving a fe
On 22 sept. 2015, at 07:57, Podrigal, Aron wrote:
> We will be using max_length=255 or 128 for the default as Shia proposed.
>
Would you mind giving a few hours for other contributors to react? I was asleep
while you were having this discussion; not every contributor is hooked to
django-develop
Aymeric, thanks for clarification, my bad I missed that one. We will be
using max_length=255 or 128 for the default as Shia proposed.
BTW how is this handled by integer_ranges on per database backend? Also,
using checks_framework can we validate this setting?
On Sep 22, 2015 1:49 AM, "Aymeric Augu
Hi Shai,
On 22 sept. 2015, at 04:22, Shai Berger wrote:
> I'd solve the "need to specify" issue by setting a default that is
> intentionally smaller than the smallest (core) backend limitation, say 128.
I would pick the highest value supported by all core backends (probably 255
for MySQL, unle
Hi Aron,
On 22 sept. 2015, at 03:12, Podrigal, Aron wrote:
> And for your concern, there will be a MaxLengthValidator added to the
> validators to validate the users input does not exceed the database backends
> maximum length just like when you set max_length explicitly.
This isn’t possible
> While this makes sense, the use of TextField is also for the purpose of
having rendered a text widget for ModelForms. So we should allow a
max_length of None for both.
If you use Oracle (or mysql I guess), you get used to manually changing the
form field widget to be a TextArea if that's what
Hi Varun,
If you believe you've found a bug, then please open a ticket on trac
here: https://code.djangoproject.com/newticket
We can then discuss on the ticket whether or not the bug exists, and I can
try to help you figure out how to fix it.
Thanks,
On Tuesday, 22 September 2015 07:06:03 UTC
Is the concern that 100,000 iterations is too slow on python < 2.7.8 but is
acceptable on versions after that? If so, then we wouldn't be breaking <
2.7.8, we'd just be reducing the performance profile, right? We could call
out such things in the release notes.
On Tuesday, 22 September 2015 02
On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus
wrote:
>
> On Sep 21, 2015, at 7:22 PM, Shai Berger wrote:
>
> > I'd solve the "need to specify" issue by setting a default that is
> > intentionally smaller than the smallest (core) backend limitation, say
> 128.
>
> I'd be OK with that. Not
On Sep 21, 2015, at 7:22 PM, Shai Berger wrote:
> I'd solve the "need to specify" issue by setting a default that is
> intentionally smaller than the smallest (core) backend limitation, say 128.
I'd be OK with that. Not wild, because I think that having to specify
max_length is good discipl
Hi,
I just went over the ticket and thread. There seem to be two concerns mixed
here.
Most people who expressed support for the feature have just been annoyed at
the need to specify a length when all they want to say is "a reasonably short
string" or "a one-liner".
Aron, on the other hand, se
On Sep 21, 2015, at 7:10 PM, "Podrigal, Aron" wrote:
> There is actually another reason to not have to specify a max_length which
> was mentioned earlier, is because most of the time you don't care about that
> and is just tedious to have to specify that when you can get it to work
> without
There is actually another reason to not have to specify a max_length which
was mentioned earlier, is because most of the time you don't care about
that and is just tedious to have to specify that when you can get it to
work without it. Default values has always been here for that reason.
On Mon, S
On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron" wrote:
> The reason for having a max_length set to None, is because that's what I want
> for my database columns to be in Postgres, and for MySQL I don't care about
> the length too, I always choose varchar(255) just for because it is required
> f
Hi,
(edited a little)
On Tuesday 22 September 2015 03:07:37 Tim Graham wrote:
> On Monday, September 21, 2015 at 6:52:08 PM UTC-4, Paulo Maciel wrote:
> > Why confused? It's optional, if the developer wanna put null=True, he
> > could.
> > I don't think need to be putting null = True, this is red
The reason for having a max_length set to None, is because that's what I
want for my database columns to be in Postgres, and for MySQL I don't care
about the length too, I always choose varchar(255) just for because it is
required for the database backend. And for validation of the max length, I
wo
Let's consider master feature frozen for now. There are two more patches
I'd like to merge before we cut the 1.9 branch.
#21231 -- Enforced a max size for POST values read into memory
https://github.com/django/django/pull/3852
Status: Needs final code reviews and probably some doc enhancements (d
On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron" wrote:
> Different schemas?? Schema will always be different for each database backend
> according to its datatypes.
It means if you specify a CharField without a length, you don't know how many
characters it can accept without error. That doesn'
Different schemas?? Schema will always be different for each database
backend according to its datatypes. I really don't understand what your
concern is. In any case your free to specify a max_length=N where it will
be the same for all backends.
On Mon, Sep 21, 2015 at 8:42 PM, Christophe Pettus
On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron" wrote:
> We're not talking about representing all CharFields as TEXT, it is about
> choosing a sane length as the default for the varchar datatype.
But that means notably different schemas on different backends, for not an
obvious gain. What's th
As Yo-Yo mentioned, there are valid use cases for blank=True, null=False,
and I believe having one field option implicitly change another actually
adds complexity instead of simplifying things.
On Monday, September 21, 2015 at 6:52:08 PM UTC-4, Paulo Maciel wrote:
>
> Why confused? It's optional
Why confused? It's optional, if the developer wanna put null=True, he could.
I don't think need to be putting null = True, this is redundant. If this is
a standard behavior, you need not be explicit.
I think this should be optional, by default these fields should always be
null=True implicitly.
D
We're not talking about representing all CharFields as TEXT, it is about
choosing a sane length as the default for the varchar datatype. So if you
would not specify max_length, for MySQL it would be varchar(255), for
oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and
for Pos
hey.I am new to django development.i asked the question with the intention
of understanding a bug im trying to solve.i want to understand the process
of how to go through the internals of django to solve a bug.The bug i was
looking at included the usage of ".annotate".Even after going through th
On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers (Contributions
to Django itself) wrote:
> I'm slightly worried from a DB point of view.
I have to agree, even speaking as PostgreSQL geek. While VARCHAR and TEXT are
implemented the same way in PostgreSQL, conceptually they're dif
THERE IS NO NEED FOR ALL CAPS IN THE SUBJECT.
That said, please write to django-users, this mailing list is for the
development of Django itself…
On Monday, September 21, 2015 at 1:16:38 PM UTC+2, varun naganathan wrote:
>
> Can anyone please explain how annotate works in django??
> I'm new to d
On Mon, Sep 21, 2015 at 5:21 PM, Paulo Maciel
wrote:
> +1 max_length optional
>
I'm slightly worried from a DB point of view. Whilst blessed
PostgreSQL supports variable length fields seemingly without issues,
other DB engines (MySQL, for instance), have significant performance
issues using a TEX
+1 max_length optional
Em quarta-feira, 29 de julho de 2015 01:27:59 UTC-3, Aron Podrigal escreveu:
>
> Hi,
>
> I am using postgresql and I prefer my VARCHAR columns not to have a length
> limit. Is there any particular reason why max_length arg to fields is
> required. If for compatibility wi
On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawebs...@gmail.com)
wrote:
> Is there an external library for Python < 2.7.8? I know we don't officially
> support the system version of python in RHEL/CentOS and Ubuntu, but I bet
> we could get away with requiring a dependency for those ol
Is there an external library for Python < 2.7.8? I know we don't officially
support the system version of python in RHEL/CentOS and Ubuntu, but I bet
we could get away with requiring a dependency for those old versions of
Python in new versions of Django.
On Mon, Sep 21, 2015 at 10:30 AM, Tim Grah
Django 1.8 is the last version to support Python 3.2 and 3.3, so I believe
we could assume Python 2.7.8+ and 3.4+ as of Django 1.9. While we only
*officially* support the latest release of each Python series, explicitly
dropping support for < Python 2.7.8 might not be acceptable, however, it
se
Can anyone please explain how annotate works in django??
I'm new to developing django and Ive been going through the source code and
am unable to figure out how it parses the query and modifies it accordingly.
any help would be appreciated
--
You received this message because you are subscribed
Hi, sorry for the delay,
On Monday, 7 September 2015 16:05:35 UTC+2, Aymeric Augustin wrote:
>
> Hello,
>
> 2015-09-07 10:00 GMT+02:00 Yann Fouillat >
> :
>
>> First I will say that most of this pull request is a port of
>> https://github.com/django/django/pull/1037 which I ported more or less
>
33 matches
Mail list logo
