Problem
Started as an issue to allow query like SELECT ... FROM ... WHERE ... AND (SELECT COUNT(*) ...) = value)
, it turns out that the new algorithm is very generic and allows for many more situations that are allowed by (standard) SQL:
- Select query at left hand side:
SELECT ... FROM ... WHERE (SELECT COUNT(*) FROM ... WHERE ...) > value
- Select query at right hand side:
SELECT ... FROM ... WHERE value < (SELECT AVG(...) FROM ...)
- Multiple select queries at right hand side:
SELECT ... FROM ... WHERE value BETWEEN (SELECT MIN(...) FROM ...) AND (SELECT MAX(...) FROM ...)
- Select query at left and right hand side (new test):
SELECT t.name FROM test t WHERE (SELECT AVG(tt.priority) FROM test_task tt WHERE tt.pid = t.id) > (SELECT AVG(tt2.priority) FROM test_task tt2)
- Select query at left hand side and multiple select queries at right hand side:
SELECT ... FROM ... WHERE (SELECT AVG(...) FROM ... WHERE ...) BETWEEN (SELECT MIN(...) FROM ...) AND (SELECT MAX(...) FROM ...)
Original post
[Note: issue #369314: Subselects don't work in DB conditions... handled only the IN case]
I was trying to construct a query with a subselect that looks like:
SELECT ...
FROM ...
WHERE ...
AND (SELECT COUNT(*) ...) = value)
However, I did not entirely manage to get it to work.
Attempt 1:
$query->condition($count_subquery, $value, '=');
Fails because $count_subquery is a SelectQueryInterface which is a QueryConditionInterface. And if the $field argument is a QueryConditionInterface it gets compiled and placed in the main query as is, thereby ignoring the $value and $operator arguments.
Attempt 2:
$query->condition($value, $count_subquery, '=');
Fails because no brackets are placed around the subquery.
This leads to a workaround:
$query->condition($value, $count_subquery, 'IN');
This happens to work because the IN operator places brackets around the value(s). However, it will not always be possible to use IN. There are times you may want to use a comparison operator other than '=', e.g. <, <=, >, >=. Also, at times, it may be necessary to compare 2 subselects (select objects whose average score is higher than the overall average score).
So, the error can be split into 2 situations:
1) SelectQueryInterface objects as the left hand side ($field operator) are not handled correctly.
2) SelectQueryInterface objects as the right hand side ($value operator) are only handled correctly when the operator happens to be 'IN'.
Proposed resolution
To solve 1)
Method DatabaseCondition::compile(): Add an additional check to this if:
if ($condition['field'] instanceof QueryConditionInterface) {
Something like:
if ($condition['field'] instanceof QueryConditionInterface && !($condition['field'] instanceof SelectQueryInterface && isset($condition['value']))) {
Subsequently the else branch needs to handle this situation, by adding:
- Compile on the $condition['field'] if it is a SelectQueryInterface.
- Brackets around that result of compile.
To solve 2)
- This will need some refactoring of the above mentioned else branch.
Remaining tasks
Can some experts regarding this part of Drupal confirm this is indeed an error and is a use case that is to be supported. Is the proposed solution in the correct direction. If so, I will try to write a patch including tests.
Comment | File | Size | Author |
---|---|---|---|
#98 | interdiff-1267508-92-98.txt | 1.31 KB | daffie |
#98 | 1267508-98.patch | 31.9 KB | daffie |
Comments
Comment #1
fietserwinError is also in D8, solve there first.
Comment #2
Agileware CreditAttribution: Agileware commentedI can confirm this bug.
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedYep, it was never intended to support sub-queries used as scalars. Let's see how to add support for this in Drupal 8.
Comment #4
Agileware CreditAttribution: Agileware commentedI have updated the documentation at http://drupal.org/node/310086 to make it clear that for now this only works with IN.
Comment #5
fietserwinThis patch includes tests that should test the proper processing of subqueries as scalars. It is test only, thus supposed to fail. Complete patch follows soon, running all tests once again locally.
@#3: It's OK, if it was not supposed to support these, but the way that placeholders are generated makes it very difficult (read next to impossible) to hack your own queries in by e.g. first processing them. So IMO, it should indeed support as much as possible.
Comment #7
fietserwinThis patch includes a solution as well. It is a rewrite of the compile() method to make it accept more situations. It will accept subconditions or subqueries at almost any place where a value is accepted. Though there is not a test for it, it should e.g. also accept 2 subqueries using the BETWEEN operator.
To make it even more flexible, we could accept arrays as operator, though that would expose the data structure used to represent operators. I'm not sure if we want that. On the other hand, it would allow for conditions using the more exotic operators like ANY, SOME, and ALL.
Comment #8
dawehnerThis patch worked fine for me on manual testing on my use case.
Can you explain this change? Isn't it a valid use case to use condition($subquery, $values); ? Perhaps some kind of comment helps as well.
Just for similarity on all other places first the value/field_fragment is created then the argument, this should probably be switch here.
In general the code is now even a bit easier to understand and described in detail.
0 days to next Drupal core point release.
Comment #9
chx CreditAttribution: chx commented$query->condition($value, $count_subquery, '=');
a subquery returns a set, a set can't be equal to a scalar. What is this issue?
Comment #10
chx CreditAttribution: chx commentedOK I eat my words. Apparently scalar subqueries http://kb.askmonty.org/en/scalar-subqueries are a standard feature where SELECT returns 1 or 0 rows.
Hell knows whether this is ANSI. http://www.akadia.com/services/ora_scalar_subquery.html Oracle 9. http://www.databasejournal.com/features/mssql/article.php/3407911/Scalar... MS SQL back in 2004. And so forth.
Comment #11
chx CreditAttribution: chx commentedDamien tells me in IRC this is standard. SQL--
Comment #12
fietserwinI changed the patch as indicated in #8:
1)
The first remark is a good catch. My local code was already different... The reason to add the check has to do that compiling the conditions now can handle a condition like "subquery IS NULL". Formerly, $operator was always set to "IS NULL" and subsequently ignored when $field turned out to be a QueryConditionInterface. Now a SelectQueryInterface, which is also a QueryConditionInterface, can be compared to NULL.
The requested comments are added to the documentation of QueryConditionInterface::condition() as that did (already before this patch) not cover all accepted situations.
2)
The 2nd remark has been processed as indicated.
3)
White space removal is not removed from the patch this time as with the previous patch. So, it may be a bit harder to read but the result will be better :).
Comment #13
fietserwinI updated the patch:
As the methods condition(), where(), exists(), notExists() and conditions() are tightly coupled around the possibilities provided by this query builder, I added/changed also documentation for those methods, even if they may bot be changed in itself. This to further clarify when to use which method and what the options/restrictions of it are.
Comment #14
fietserwinCan this be rewritten now that #1321540: Convert DBTNG to namespaces; separate Drupal bits has landed or are there more disturbing patches to be expected soon?
Comment #15
kiranjala CreditAttribution: kiranjala commented#7: 1267508-subselects.patch queued for re-testing.
Comment #16
kiranjala CreditAttribution: kiranjala commentedplease ignore the above request.
Comment #17
DanZ CreditAttribution: DanZ commentedI want to do this:
...or...maybe better:
All of this is a bit over my head. Does the fact that this issue isn't fixed mean that I can't do this with the regular db_select() calls? See http://drupal.stackexchange.com/questions/18497/how-do-i-use-not-in-in-a....
Comment #18
dawehnerYou can certainly do this with notExists($sub_query) ... in general: try to avoid posting somehow support questions in non-support issues. This doesn't really help to move the issue forward, so better test the patch for example.
Comment #19
fietserwinI would like to have another look at it and rewrite it to current head, but know that my time will be too limited to do it in the near future. I will reassign to me if I do find time to work on it though.
Comment #20
tcarmona CreditAttribution: tcarmona commentedHi, sorry to necro this one, as the last comment was about a year ago.
Is there still need for work on this post? What is the current status? I'm willing to work on this issue if it there isn't a solution.
Comment #21
fietserwinThe last patch was against the procedural code. So it needs to be rewritten against the current OO code. I have no idea how much of the internals really changed. If not that much, it might be more of logically "relocating" the changes. If yes, the current patch will only guide you by the logic of it.
Thanks for picking this up, I promise to review it quickly.
Comment #22
chx CreditAttribution: chx commentedPlease look at #1837118: UPDATE foo SET bar=(SELECT...) is not supported for a similar problem + accepted solution.
Comment #23
fietserwinThey are indeed related as the crux of that patch indeed also appears in this patch. However, this patch is about improved handling of conditions in the where clause, where the subquery may be at the left side, right side or both sides and all kinds of operators may be used. The other patch is about handling the set clause where subqueries can only appear at the right hand side and the operator is always =.
Thus this issue is still valid on its own. So, @tcarmona, if you want to give it a try, go ahead. A large part of the query is documentation improvements, as a few years ago I found that it was lacking to describe the full capabilities of the query conditions. I don't know if that has improved since.
Comment #24
chx CreditAttribution: chx commentedYes the issue is certainly valid I was just suggesting the other issue for the architectural solution, calling compile and such . If this is not enough, I can dig it up what we did over there, I certainly can't remember it's been *ages* since that one but I'd be glad to do dig into it and help this issue be fixed.
Comment #25
fietserwinUpdated the patch to the current state of the database code. It was mainly new locations for the files and some class name changes (due to namespacing). Let's see if other tests now fail (I caught one that did a match on the generated query text, while the condition compiler now uses less spaces and brackets.
Comment #26
lisa.ugray CreditAttribution: lisa.ugray at University of Ottawa commentedHere's a much simpler patch more suited to the current state of D8. I've marked this as a bug report and not a feature request since the documentation suggests this should work, and this is standard SQL syntax. The -FAIL.patch adds a test that demonstrates the problem, and the other patch has the test and the fix.
Comment #28
fietserwinMuch simpler indeed, but it looks like it doesn't solve the first error in the issue summary: a sub select at the left hand side makes the code ignore the operator and value arguments (attempt 1).
So, to progress, I think it would be better to get back to my patch in #25 and see if that still works and review that one.
Comment #32
daffie CreditAttribution: daffie commentedI have to agree with fietsenwin. The fix from lisa.ugray is a good find, but for me a quit and dirty fix. I do like the fix from fietsenwin.
I was not able to do a easy reroll for that fix from the fietsenwin patch. The tests for that patch where easily rerolled. The tests from the patch are the ones we need to test any solution.
I would like to get this issue fixed. And I will do so by reviewing.
Comment #34
daffie CreditAttribution: daffie commentedComment #35
fietserwin"Manual reroll" from patch #25 (and including the tests from #32).
Some remarks:
Comment #37
fietserwinComment #39
fietserwinI forgot to "reroll" the detection of the 1 argument call to condition() as with the new parameter defaults that had to be done differently.
Comment #41
fietserwinAnd the detection of conditions created via the where method was not done correctly...
Comment #43
fietserwinAnd the tests (a lot more then before) that failed because the new compiler outputs less superfluous spaces and brackets. They pass locally, so this one should turn green.
[EDIT: after the 1st green, I added 2 other databases to test]
Comment #44
daffie CreditAttribution: daffie commentedI will do a full review later. But for now the testbot for SQLite is returning the syntax error: Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1 near "(": syntax error. You made a lot of changes where you removed the space before the round bracket. I think that is the source of the SQLite bugs.
Comment #45
fietserwinYeah, yesterday, I didn't have time to look at it anymore. I cannot really find any syntax error in the query though, unless sqlite chokes on to many (!) brackets in this part "AND (EXISTS ((...)))".
I had a good look at when and where brackets are expected and decided to make some small changes:
- Each subquery (field or value) gets always brackets around it.
- Thus EXISTS and NOT EXISTS (that only accept a subquery) do not need brackets as pre and postfix anymore: this prevents the double brackets around an EXISTS subquery.
- 'BETWEEN' as an operator does not have its NOT BETWEEN counterpart in the list of supported operators (mapConditionOperator). I added that, though strictly speaking this may be out of scope.
I will start with testing mysql first and add other database tests later.
Comment #46
daffie CreditAttribution: daffie commentedSome remarks after a short review:
Not sure if we have testing for this. I cannot find it.
Nitpick: Must be
elseif
.Can you explain this one to me. Can $condition['field'] be an instance of ConditionInterface and SelectInterface?
We have #2686483: Add support for database condition operator "NOT BETWEEN" for adding the "NOT BETWEEN" operator. If this is needed we can postpone this issue on that.
Are we allowing that there be an array of select statement in the $condition['value']? This is something that I do not like. Maybe a test to make sure that it is not allowed.
Comment #47
fietserwin#46: Thanks for the review.
SelectInterface extends ConditionInterface
, so it is possible and can be used as is tested in testConditionSubquerySelect3():and
I will update the IS to reflect what becomes possible and then we can see if we want or need tests for all those situations.
Comment #48
fietserwinComment #49
daffie CreditAttribution: daffie commented@fietserwin: Thank you for your explanations. Your two changes for the patch from comment #47 look good.
I you want to support multiple select queries at right hand side, then extra tests for that are needed.
Comment #50
fietserwinAdded a test.
Comment #52
oriol_e9gMinor: Asserts messsages doesn't need to use t().
Comment #53
fietserwinThanks, removed. Waiting for Postgress result and then setting to NR again.
Comment #54
daffie CreditAttribution: daffie commentedFor the testbot.
Comment #55
daffie CreditAttribution: daffie commentedThe problem as stated in the issue summary is fixed with this patch.
There are tests added to check the fix.
The patch looks good to me.
I am giving this a RTBC.
Good work fietserwin!
Comment #57
daffie CreditAttribution: daffie commentedNeeds a reroll, because #2686483: Add support for database condition operator "NOT BETWEEN" is in.
Comment #58
fietserwinRerolled. No other changes.
Comment #59
fietserwinForgot a few comment lines while rerolling.
Comment #60
daffie CreditAttribution: daffie commentedThe test failures for PostgreSQL are not related to this patch.
The reroll looks good.
Back to RTBC.
Comment #61
alexpottI wonder what the impact for other db drivers this will have.
This looks like a pretty tricky API change.
There's assertCount()
There are special phpunit asserts for this ie. assertArraySubset()
As above
Comment #62
fietserwin#61: Thanks for reviewing.
RE #61.1: Will try to set up something later today, but if someone else, a native English writer, want to give it a go, please do so, but add a comment that you are going to do so.
Re #61.2: With the patch of #43 we discovered that SQLite choked on to much brackets, therefore I had to make this change. We have positive test results for MySql, Postgres and SQLite. I guess that contrib provided drivers (Oracle and MSSQL server?) will not experience problems, resulting syntax is standard SQL. In fact, the method most touched by this patch (compile())is called hundreds or thousands of times per request, so that will be clear quite fast.
RE #61.3: No, this is only documenting what already existed. When I started working on this (back in 2011) I had a hard time figuring out what many of the methods returned, so I documented all those methods involved
RE #61.4/5/6: Changed. The tests were written in 2011 and only rerolled since. I also updated other usages of the deprecated assertEqual(). BTW: Is there an assert to check that arrays contain the same values (which is notably hard in PHP)?
Comment #64
daffie CreditAttribution: daffie commented@fietserwin: One test fail to fix: testConditionSubquerySelect2 with "fail: [Other] Line 98 of core/tests/Drupal/KernelTests/Core/Database/SelectSubqueryTest.php:
0 => 'Paul'".
Comment #65
daffie CreditAttribution: daffie commentedI shall write the change record.
Comment #66
daffie CreditAttribution: daffie commentedChange record added.
Comment #67
fietserwinassertArraySubset() takes order (indices) into account. [My BTW turned out to be prophetic :).] However, it turns out that assertEquals has a $canonicalize parameter that sorts array before comparing them. This parameter turns this assert into a check on whether both arrays have the same values (with the same cardinality).
Interdiff is against #59
[@daffie: Thanks for writing the change record]
Comment #69
daffie CreditAttribution: daffie commentedThe test failure for SQLite has noting to do with the patch for this issue.
All remarks of alexpott are addressed.
All changes look good.
Back to RTBC.
Comment #71
daffie CreditAttribution: daffie commentedBack to RTBC.
Comment #72
alexpottDiscussed @catch, @effulgentsia and @cottser we agree this needs to be in before the beta is cut on Tuesday. If this is not in before then it'll need to be for 8.3.x because whilst this probably won't impact other drivers - we can not be sure.
Comment #73
alexpottIt'd be great if a sub system maintainer could have a look at this. Afacis the solution is solid and works great and has test coverage.
Comment #74
Crell CreditAttribution: Crell at Platform.sh commentedFirst off, I *adore* how detailed the comments are in this patch. Well done!
The code overall looks fine as is, and if committed as is I wouldn't block it. However, I do have a few small nits:
Total not-blocking nitpick: I generally prefer to convert double-conditionals like this to an in_array(), as it's shorter and easier to read. (Vis, in_array($operator['operator'], ['IN', 'NOT IN']) )
May as well use short-array syntax while we're here.
No comma after where().
One larger, note, though, is that the compile() method is now quite long (even longer than it was before), and very deeply nested. That results in a very high cyclomatic complexity. Is there any way we can break it up into a series of sub-methods? At minimum, it looks like the main foreach()'s body could get split off to a sub-method. There may be others, or it may just to too complex to do, but it would be great if we could at least try.
If doing so is the difference between this patch being committed to 8.2 or not, though, I'm OK with committing it and tidying that up later.
The SQLite and Postgres fails are concerning, though. #69 indicates they may be spurious, so I defer to the committers on that front.
Comment #75
daffie CreditAttribution: daffie commented@Crell said:
Removing the tag "Needs subsystem maintainer review".
Created a followup #2775819: The method Drupal\Core\Database\Query\Condition::compile is too long and complex for:
I think that the 3 minor points of comment #74 can be fixed on commit.
Comment #76
fietserwin@crell: thanks for reviewing so quickly.
This patch basically stems from 2011 and has since "only been rerolled" to move with all the D8 changes. So, e.g. [] did not yet exists back then, also making in_array(...,array()) a little bit more awkward then nowadays. Comments (and doc added on a number of places) are for "compensating" the complexity and - for myself - to get a grip on what was going on and what could be expected (setting the expectations by writing correct preconditions).
1 to 3 can indeed be done on commit.
The fails do seem random (memory limit?) and with none of them I am able to track it back to a DB failure, while e.g.back in #43, the exception message and/or stack trace were clearly indicating that it was a failure due to the patch. This can be lack of logging the correct exception message at the origin of the failure or it has indeed not to do with this patch. Moreover,at this moment, the current dev branch without this patch also fails on d6\MigrateBookTest.
Comment #77
alexpottThanks @Crell for the sub system maintainer review..
There's been some discussion of whether this is a bug or feature - let's split the difference and call it a task.
Committed 22a241c and pushed to 8.2.x. Thanks!
Fixed on commit. I can't do #74.1 on commit - it's a code change plus
in_array()
is a tricky beast - you (nearly) always want to make the 3rd argument TRUE so it doesn't produce unexpected results.Comment #79
andypostLooks this needs follow-ups - port to d7 and simplify code
Comment #80
daffie CreditAttribution: daffie commented@andypost: There is a follow-up for the compile() method: #2775819: The method Drupal\Core\Database\Query\Condition::compile is too long and complex.
Comment #83
BerdirIt seems like this caused a test fail in TMGMT.
\Drupal\tmgmt_locale\Tests\LocaleSourceUiTest is failing.
We have a condition like this:
$select->isNull("lt_$missing_target_language.language");
$missing_target_language in this case is 'gsw-berne'. That used to be converted to gswberne, but no longer.
Maybe that's on purpose and can't be avoided, but I'm not sure?
We already have other places where we explicitly escape..
The code is in \Drupal\tmgmt_locale\LocaleSourcePluginUi
Comment #84
fietserwin#83:
For now I can't see any link. This patch should not change existing already allowed queries, except that far less spaces and brackets are generated. So if someone is testing on literal query strings that will fail, but testing on query results should still work as before.
- Exactly which test is failing?
- How is it failing? Fatal error, uncaught (db) exception?
- Can you isolate the query that fails and more specifically the string version of it (e.g. dump all queries as string in execute()).
- Does it fail on a specific db or all dbs?
If this adapted compile() can generate where clauses with syntax errors I will immediately solve it.
Comment #85
BerdirThe failing test is in my comment, you can also see it here: https://www.drupal.org/pift-ci-job/413927, including the incorrectly generated query. I'm 100% sure that this issue changed that behavior, the only question is if that is a bug or by design. The test passes on the commit before this and fails with this.
Note that it only fails on the error_log parsing, on the terminal, the test is reported as passing.
Comment #86
fietserwin@berdir: thanks for reporting. The committed patch indeed contains a small but highly critical omission. Please all review the follow-up issue #2783165: Follow up to "Subselects don't work in DBTNG conditions, except when used as value for IN".
Aside: @berdir: theoretically speaking, your code should use db_escape_table() instead of db_escape_field(). But as the standard implementation is the same it does not really matter, although on postgress they do differ.
Aside 2: The standard escapeField() implementation does not allow for
alias.field
to be passed as field part as it will be escaped toaliasfield
. This seems an error to me, but one that should have been discovered ages ago, so I am not sure about this.Comment #87
fietserwinFYI: The query that fails and lead to @berdir's report gets (currently) compiled as follows:
Also see:
- http://cgit.drupalcode.org/tmgmt/tree/sources/locale/src/Tests/LocaleSou...
- http://cgit.drupalcode.org/tmgmt/tree/sources/locale/src/LocaleSourcePlu...
Comment #88
BerdirThanks for the feedback. We already opened #2783123: Fix escape condition in \Drupal\tmgmt_locale\LocaleSourcePluginUi, we'll try to implement your feedback there. Reviews would be great :)
Comment #91
catchI've reverted this due to #2783165: Follow up to "Subselects don't work in DBTNG conditions, except when used as value for IN" - that bug is worse than the limitation this fixes, and no need to have time pressure on fixing the security issue. Also bumping to 8.3.x
Comment #92
daffie CreditAttribution: daffie commentedFrom #2783165: Follow up to "Subselects don't work in DBTNG conditions, except when used as value for IN":
The patch has added fix for the problem and also has added testing for it. The second patch has only the added testing.
Comment #93
fietserwin- #3.1 from the other issue is not addressed. I thought that "provider function" from your comment had to do with addressing that comment, i.e. introducing some kind of "function provider", instead of using a data provider function.
- #74 (this issue) has not been addressed by this patch while #74.2. and #74.3 had been addressed on commit (I think).
Comment #94
daffie CreditAttribution: daffie commentedWrong patch for 1267508-92-without-the-fix.patch.
Comment #96
daffie CreditAttribution: daffie commentedThe patch with the fix and the added test passes and the patch with only the added test fails.
Ready for a good review.
Comment #97
fietserwinNot according to the Drupal standard (In Drupal description comes before @var)
I never touched this statement and it is also probably out of scope for this issue but I think that comment starting characters should also be part of the list of dangerous characters: for Mysql:#-/ (for #, -- resp. /*). Minus is an operator in itself but is not a comparison or logical operator.
LIKE (instead of LIke)
Furthermore the release version in the change record should be updated.
I found some other minor points bu they are not part of this patch:
- 80 character limit violations on some comments.
- 1 untyped property ($queryPlaceholder)
- missing operators in the map: !=, <> (will work but according to the comment a small "performance hit").
Comment #98
daffie CreditAttribution: daffie commented@fietserwin: Thank you for the review!
For 97.1 and 97.3 Thanks and fixed!
For 97.2 That line is not being changed, but it is being moved. This is also happening in your own and previous commit patch from comment #67.
For:
and
Please create follow-ups for those. I am happy to do the reviewing for them.
Comment #100
daffie CreditAttribution: daffie commentedTestbot is happy.
Comment #101
fietserwinOK, good to go again. Can you change the version number in the change record?
Comment #102
daffie CreditAttribution: daffie commented@fietsenwin: Thanks and I updated the change record.
Comment #103
alexpottI would nice to confirm that the updated fix does not cause the same issue for @Berdir's contrib module.
Comment #104
daffie CreditAttribution: daffie commented@alexpott: That is what I did in the comments #92 and #94.
Comment #105
fietserwinSo the failing test in contrib has now explicitly been tested with this patch and doesn't fail anymore.
Comment #107
daffie CreditAttribution: daffie commentedBack to RTBC.
Comment #108
chx CreditAttribution: chx at Smartsheet, Migrate Rocks commented19 fails in SQLite is OK?
Comment #109
daffie CreditAttribution: daffie commented@chx: The latest automatic testing without a patch has 16 fails. See https://www.drupal.org/pift-ci-job/435525.
Comment #110
daffie CreditAttribution: daffie commentedI created an issue for the problems with the testbot for PHP 5.5 & SQLite. See #2791163: Random automatic testing failures on SQLite with PHP 5.5.
Comment #111
chx CreditAttribution: chx at Smartsheet, Migrate Rocks commentedLook, it's fine by me, as far as I am concerned @daffie is already the SQLite maintainer, I already encouraged them to make it official.
Comment #113
catchCommitted/pushed to 8.3.x, thanks!