>
> As far as I'm aware, the user is responsible for creating the database so
> I'm not sure why a setting is needed here. Maybe someone can enlighten me.
This is not the case in tests, so a setting would be needed there at least.
(Also I don't like the "create your own DB" approach of Django, i
I just want to follow up on this as there is one remaining collation
related ticket left: https://code.djangoproject.com/ticket/5745
Reading through, it requests two things: a setting in DATABASES for a
collation and a model Meta option for table collations.
As far as I'm aware, the user is respo
> I like this idea, but I think we'd still want to offer the option of
using strings, since most projects run only against one database backend.
Compilable objects would be more effort so perhaps best to leave for now,
at least until the PR is much more developed.
Makes sense, lets focus on onl
>
> I like where it's heading but I wonder if it'd be more appropriate to
> start by supporting a _compilable_ object instead of a string at first.
>
I like this idea, but I think we'd still want to offer the option of using
strings, since most projects run only against one database backend.
Compi
Thanks for your work so far Tom!
> There is perhaps some scope in the future to make this take a callable
that can figure out the collation per-database. This would be useful for
getting case-insensitive lookups working across all backends, for example.
But I want to keep that out of the scope
Thanks for the feedback.
Aymeric, yes, I left out modification until I knew there was some interest
as that code seemed more impenetrable to me than the field addition. I've
added this now, does it seem like the right approach? I've tested it on
everything but Oracle and it seems to work as I'd ex
Yes I'd also like to lend my support.
In MySQL (at least) columns also have a charset property that goes
hand-in-hand with which collations are available. I know it expands the
scope, but I think it would be good to get that in here. Perhaps it could
be a follow-up ticket though.
On Sun, 19 Jul 2
Hello Tom,
Just wanted to give you some encouragement here, as you've been monologuing for
two months ;-) The PR looks promising!
Regarding migrations, I'm not seeing how the collation for a column will be set
or unset in the database if you change it in the code e.g.:
MySQL : ALTER TABLE ...
I've written a proof of concept: https://github.com/django/django/pull/13207
The diff is quite small, though I'm not sure if there's something I'm doing
wrong - this is my first foray into schema migration internals so I'm
learning as I read the codebase.
Tom
On Fri, 17 Jul 2020 at 13:55, Tom Ca
I've had a deeper look at this now and think I have an API proposal. First,
the state of supported vendors:
1. All vendors support adding a collation to text/varchar fields.
2. The syntax is more or less the same.
3. However, the collation names themselves are different.
4. PostgreSQL is the only
10 matches
Mail list logo
