On Mon, Apr 22, 2019 at 08:40:05PM +0200, Christoph Zwerschke wrote:
> Am 22.04.2019 um 20:35 schrieb Justin Pryzby:
> >Isn't it a best-practice to make a subclass of ProgrammingError just for
> >that ?
> >Else it encourages people to write "except ProgrammingError:" without also
> >checking "if 'exactly one row' in e".
>
> Good point. How shall we call it?
>
> Maybe "NoResultFound" and "MultipleResultsFound" like in SQLAlchemy?
>
> Or just "NoSingleRow" encapsulating both?
For ntuples==0, query() returns [].
I suggest that single() should return None for n==0, and MultipleResultsFound
for n>1.
Commentary follow...
Last year, when I was implementing for telsasoft use of schemas (PG
namespaces), I grepped for stuff like "getresult()[0][0]", which could lead to
undefined/nondeterministic results.
I put in place for our DB layer:
class NotOnlyOne(Exception):
""" Raised when multiple rows returned but not expected """
pass
...
if len(res.getresult()) > 1:
raise NotOnlyOne
You're right, that could handle the 0 case as well, and so the name I used
isn't great in the way I used it...
If you wanted to be really extreme you could have THREE subclasses...
|class NotOnlyOne(DataError):pass
|class MoreThanOne(NotOnlyOne):pass
|class LessThanOne(NotOnlyOne):pass
Quote. There are only two hard things in Computer Science: cache invalidation,
naming things, scope creep, and off-by-one errors.
Justin
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo/pygresql
