On Tue, 11 Aug 2020 10:51:58 -0700 (PDT)
charettes wrote:
> > Suffix-hashing long names like Simon suggests may not be
> backwards-compatible.
>
> Could you elaborate on that?
>
> Assuming model names > 100 characters never worked wouldn't only
> suffix-hashing model names > 100
I think a problem with hashing names here is that it would break the whole
`apps.get_model(, )` functionality that content
types uses, as the model name stored in the db is not the actual name
stored in the apps registry (and modifying the registry functionality feels
like the wrong approach
> You should be able to work around this for now with a migration in your
own app that uses RunSQL to alter the column for ContentType.model.
I tried this approach however the ORM level field validation still kicks as
it still expects VARCHAR 100 even if the db column is now a different type.
> Suffix-hashing long names like Simon suggests may not be
backwards-compatible.
Could you elaborate on that?
Assuming model names > 100 characters never worked wouldn't only
suffix-hashing model names > 100 characters be backward compatible?
Simon
Le mardi 11 août 2020 à 12:05:46 UTC-4,
AFAIK Postgres, in these cases, simply truncates the name. This means:
1) Generating models with names longer than 63 characters on postgres
is fragile. You may find yourself with more than one model trying to
use the same table name.
2) Suffix-hashing long names like Simon suggests may not be
I agree this limitation of `contrib.contenttypes` is a bit unexpected. Not
saying we should lift it but it does seem arbitrary even if having such
large table names could be considered bad practice.
One approach we could take that doesn't involve any migration is to
fallback to hashing of the
*contenttypes* should support all backends, You need to remember about
DB-restrictions, e.g. we cannot change `ContentType.model` to a `TextField`
because TEXT columns cannot be used in unique constraints on MySQL. See similar
discussion
It does seem unreasonable. I think a migration to TextField would be
warranted.
You should be able to work around this for now with a migration in your own
app that uses RunSQL to alter the column for ContentType.model.
On Tue, 11 Aug 2020 at 04:26, Richard Campen
wrote:
> I guess I have two
I guess I have two answers to that:
1) Specifically, in this instance I am scripting the creation of a whole
bunch of Django models as there are too many to do manually. A couple out
of the hundred or so models have names that are just over 100 characters
(102, 103, etc) which is where I found
I’ve never needed a Django model with a name that long, but I don’t think
it’s the framework’s place to make those sorts of assumptions if it doesn’t
need to, especially for what I see as little to no gain.
On 11 August 2020 at 11:18:49 am, אורי (u...@speedy.net) wrote:
How can a class name be
How can a class name be more than 100 characters? Can you give an example?
A limit of 100 characters seems reasonable to me, maybe even 60 would be
enough.
אורי
u...@speedy.net
On Tue, Aug 11, 2020 at 6:06 AM Richard Campen
wrote:
> Hello
>
> I have hit what I feel is an arbitrary limit on
Hello
I have hit what I feel is an arbitrary limit on the length of a django
model class name. I am using the PostgreSQL backend, which smartly
truncates table names above a certain size (normally 63 characters) which
means in theory a table name can be of indeterminate length, as PostgreSQL
12 matches
Mail list logo
