Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add 'rawSql'. #34
added a commit
this pull request
Jan 1, 2012
Very nice! =D
Note that there's one bug that I think that may be relatively easily fixable and we should go for it before releasing persistent 0.7. If one uses
So I see two possible venues that may be explored for a solution:
a) Somehow create placeholders for selectors. So the user may write something like
This is actually possible to be done for
b) Somehow make SQL backends return the names of the columns in the result as well. Then our code would be able to re-order the column order before calling
So b) is easier for our users in the sense that they don't need to learn about two different placeholder notations. However, a) should be more efficient and requires a lot less changes: namely only on code that was brought by this pull request. Note also that we could use the same placeholder
Unfortunately this bug does happen in practice since I've been bitten by it myself =).
What do you think?
I have no real opinions on what's the best approach here. We could in theory be even more invasive, and automatically rewrite "Entity".* to the correct list of fields. That would likely solve the problems, though it starts to get into the area of being too smart for our own good.
Greg, because their order also affects the order of the fields on the Haskell side, so that's a PITA.
I'm leaning towards a). The only downside I see (namely having another kind of placeholder -- same symbol or not) does not outweights the benefits. OTOH, b)'s performance downside is a huge one, since I don't know off the top of my head an efficient method of doing this kind of reordering.
Michael, on one hand I like your suggestion because we don't need to introduce unfamiliar placeholders. OTOH, once you get where to put
I don't like b) as stated either until performance is first bench-marked. We are doing that in persistent-mongoDB out of necessity.
Maybe it is possible (in conjunction with migration code?) to get a mapping of column order at startup time. Rails actually does this to some extent.