Extend ToRow and FromRow to tuples of size 18 #229
Conversation
The latest GHC 7.6.x was in Apr 2013 and it seems that trying to build with it on Travis fails because one or more of the dependencies fail to compile.
|
Not opposed, though you can use |
|
Sure, we can do 20 :). I actually just chose 18 just for the aesthetics of the last entry :). I'll do a follow-up with 20 in a bit. (Hadn't noticed the |
|
Well, if you like the aesthetics, maybe we could go to 24 or 30, which are very round numbers (IMO). But maybe we would be getting carried away at that point? |
|
20 it is :). |
BardurArantsson
force-pushed
the
bigger-tuples
branch
from
b2d657d to
0ce5ba4
Compare
|
Branch updated, incidentally also discovered that I'd missed an 'intermediat-sized' instance of FromRow. |
| instance (FromField a, FromField b, FromField c, FromField d, FromField e, | ||
| FromField f, FromField g, FromField h, FromField i, FromField j, | ||
| FromField k, FromField l, FromField m, FromField n, FromField o, | ||
| FromField p, FromField q, FromField q, FromField r, FromField s, |
There was a problem hiding this comment.
FromField q, FromField q? Should be harmless, but superfluous.
| instance (FromField a, FromField b, FromField c, FromField d, FromField e, | ||
| FromField f, FromField g, FromField h, FromField i, FromField j, | ||
| FromField k, FromField l, FromField m, FromField n, FromField o, | ||
| FromField p, FromField q, FromField q, FromField r, FromField s) => |
There was a problem hiding this comment.
And here as well (see comment for line 423)
There was a problem hiding this comment.
Nice catch! It's pretty hellish to do this manually. Will fix later today and update the PR :).
BardurArantsson
force-pushed
the
bigger-tuples
branch
from
0ce5ba4 to
bd8a12b
Compare
|
Should be fixed now, thanks :). |
2 participants
(I've taken the liberty of including the GHC 7.6.x commit in this just to avoid the spurious Travis CI error. Feel free to drop that commit if you want to.)
I realize that tuples of this size aren't exactly ideal, but I'm actually hitting the rather low limit in UPSERT-style scenarios where the number of query parameters are usually about double that of normal queries. I'd rather not have to write newtypes for single queries :).