New mash type are behaving poorly #244
Comments
mikfire
pushed a commit
to mikfire/brewtarget
that referenced
this issue
Apr 23, 2016
According to both sqlite and postgres, the order in which rows are returned is undefined unless an order by clause is used. In postgres, it seems "undefined" means random. In sqlite, it seems "undefined" means in row-id order. When we got the mash steps, we didn't specify the order. It happened to work for sqlite, but not for postgresql. This patch adds an order by clause to make sure it isn't "undefined".
|
I think I have it this time. As a side question, is there a reason we load everything, everything, everything on startup? Could we maybe find a way to load only what is needed first (like whatever tree is focused, plus what is needed to display the recipe + ferms) and then load the rest as we need it? It would make the remote database stuff much faster. |
Because that's how it used to work in-memory?
Sure, if there is a principled way to figure that out. |
mikfire
added a commit
that referenced
this issue
Apr 26, 2016
Closes #244 -- New mash type are behaving poorly (for reals)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just created a new recipe. If I do a double batch sparge with a grist ratio of 1.5 qt/lb, I get a warning saying that there is more liquid than mash tun. If I do a double batch sparge at a grist ratio of 2, no warning and the math works.
The sort order is also a little out of whack.
Finally, I missed a few qDebug statements in there somewhere.
The text was updated successfully, but these errors were encountered: