Re: Default ordering option

From: Cyril Champier <cyril(dot)champier(at)doctolib(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Default ordering option
Date: 2019-07-26 08:14:24
Message-ID: CAJaA8Vf58WvDmYPXNoOPgYpAuDpvP+u9uvkL2D_2mzt5MZL-nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Julien,

Because it's production code generated by our ORM for this command:
`Patient.find_by(last_name: 'champier')`.
Of course this was not intended by the developer that though the last_name
was unique.

On Fri, Jul 26, 2019 at 10:10 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> On Fri, Jul 26, 2019 at 9:53 AM Cyril Champier
> <cyril(dot)champier(at)doctolib(dot)com> wrote:
> >
> > Adrian:
> >
> >> Are you really looking for a pseudo-random name?
> >
> >
> > No, the code I pasted was an existing production bug: the last_name
> should have been unique, so the selected patient would always be the same.
> > This should have been detected in tests, but since the order was "almost
> always the same", our test was green 99% of the time, so we discarded it as
> flaky.
>
> If the filter should return at most 1 row, why put a LIMIT in the
> first place? Even with a forced random() you won't get a failure
> every time, while asserting there's at most 1 row returned is
> guaranteed to fail?
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2019-07-26 08:46:18 Re: Too slow to create new schema and their tables, functions, triggers.
Previous Message Julien Rouhaud 2019-07-26 08:10:24 Re: Default ordering option