This discussion started because a user wants to leave off max_length for
postgres, which allows the max_length to be omitted right? Is there
anything wrong with `from django.contrib.postgres.fields import CharField`?
The postgres specific CharField will allow max_length to be optional
without
I've a specific set of models:
class Parent(models.Model):
pass
class ChildA(Parent):
pass
class ChildB(Parent):
pass
Here Parent has fields:
(,
,
)
and ChildB has fields:
(,
)
so fields childa and childb are not inherited in ChildB, which is normal
and expected. But
Hi,
I just experienced the following behaviour and would like to ask for
your opinion whether I should file this as a bug or whether this is
intended behaviour. I today had the pleasure to work with a crashed
memcached deaemon that could not restart because of a permission
problem. In this case,
Regarding custom sentinels for values vs custom sentinels for missing values:
The added complication in this case is migrations, and migrations that support
multiple Django versions, as is common in 3rd party apps. I haven't thought
through the implications, but it is vital to do so, because
There is a precedent to this (although it seems to happen at startup time
rather than save time), we loop through all the connections and check that
max_length has a value supported by their backend:
https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.
I don’t
On Sunday 28 February 2016 12:23:50 Florian Apolloner wrote:
> On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote:
> > We could also potentially add another sentinel like
> > DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly
> > documented, for the sake of 3rd
On Sunday, February 28, 2016 at 11:33:16 AM UTC+1, Loïc Bistuer wrote:
>
> I don't think this is a problem, we could validate that the backend
> supports it during save then blow up if we detect it doesn't. I think we do
> that for truncation on MySQL. If the model specifies something that the
I don't think this is a problem, we could validate that the backend supports it
during save then blow up if we detect it doesn't. I think we do that for
truncation on MySQL. If the model specifies something that the db doesn't
support it's a configuration problem, not a user validation problem.
On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote:
>
> We could also potentially add another sentinel like
> DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly
> documented, for the sake of 3rd party apps, and comes with the caveat that
> it produces different
Replying to this and the other emails in the thread:
Django should not be settling low arbitrary limits for the sake of a database
I'm not even using, that's just crazy. Limits as high as 120 are not "big
enough for anyone", and will cause problems. (I can give lots of examples).
Maximum field
On Saturday 27 February 2016 23:57:19 Florian Apolloner wrote:
> Hi Shai,
>
> On Saturday, February 27, 2016 at 4:44:18 PM UTC+1, Shai Berger wrote:
> > I think this is why we should be a little more cautious and go for 128 or
> > 100,
> > rather than "the current maximum all-backend-compatible
11 matches
Mail list logo
