Open Stack

On Mon, 13 Aug 2018 at 16:56, Chris Friesen <chris.friesen at windriver.com> wrote:
>
> On 08/13/2018 08:26 AM, Jay Pipes wrote:
> > On 08/13/2018 10:10 AM, Matthew Booth wrote:
>
> >> I suspect I've misunderstood, but I was arguing this is an anti-goal.
> >> There's no reason to do this if the db is working correctly, and it
> >> would violate the principal of least surprise in dbs with legacy
> >> datasets (being all current dbs). These values have always been mixed
> >> case, lets just leave them be and fix the db.
> >
> > Do you want case-insensitive keys or do you not want case-insensitive keys?
> >
> > It seems to me that people complain that MySQL is case-insensitive by default
> > but actually *like* the concept that a metadata key of "abc" should be "equal
> > to" a metadata key of "ABC".
>
> How do we behave on PostgreSQL?  (I realize it's unsupported, but it still has
> users.)  It's case-sensitive by default, do we override that?
>
> Personally, I've worked on case-sensitive systems long enough that I'd actually
> be surprised if "abc" matched "ABC". :)

To the best of my knowledge, the hypothetical PostgreSQL db works
exactly how you, me, and pretty much any developer would expect :)
Honestly, though, SQLite is probably more interesting as it's at least
used for testing. SQLite's default collation is binary, which is
obviously case sensitive as you'd expect.

As a developer I'm heavily biased in favour of implementing the
simplest fix with the simplest and most obvious behaviour, which is to
change the default collation to do what everybody expected it did in
the first place (which is what Rajesh's patch does). As Jay points
out, though, I do concede that those pesky users may be impacted by
fixing this bug if they've come to rely on accidental buggy behaviour.

The question really comes down to how we can determine what the user
impact is for each solution. And here I'm talking about all the
various forms of metadata, assuming that whatever solution we picked
we'd apply to all. So:

- What API calls allow a user to query a thing by metadata key?

I believe these API calls would be the only things affected by fixing
the collation of metadata keys. If we know what they are we can ask
what the impact of changing the behaviour would be. Setting metadata
keys isn't subject to regression, as this was previously broken.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)