Closed hujiyang closed 10 years ago
I'm not sure if I like this. It will produce unexpected query results and some debugging pain + the code you pushed is broken (using $op
where it's not available)
@kemo I like the idea that passing an empty IN array will return an empty result rather than throwing - I sort of think that is expected. I use that pattern elsewhere and it does make it easier to handle some cases in particular where the list of items for the IN is dynamic.
But obviously the code would need to work, and ideally be covered by a unit test.
@acoulton I like the idea, just don't like how the query gets changed. IMO it should dismiss empty IN() statements at query compilation time
@kemo yeah, that makes more sense probably.
That looks goodI think somay be very useful!
up~32 ups~
32 zans!!!!
geilivebal ..
Sorry to close this as it targets the master
branch. @hujiyang if you can make another PR targeting 3.3/develop
and taking into consideration @kemo's comment? Also, kindly add some unit tests as @acoulton suggested :)
Thanks!
Also, these commits need better messages. This is unacceptable. At the very least commit messages need to reference issue numbers.
@zombor, better messages is needed indeed, the title generated automatically by Github is not enough. But we can find PRs of commits by entering its SHA into the search bar.
PRs should be rejected by default if they don't supply a sufficient commit message describing in detail what was changed and what issue it references. Describing this stuff in the PR description is nice, but it needs to be in the commit instead. Github is not the end-all-be-all data source for history. The repository itself is.
Hmm, I understand now what you mean @zombor.
Yes, this was bothering me as well. Note that when you supply a good commit message, github will auto fill it in the description.
Use the first line as a summary, then leave a blank line, and then explain why the change is made. On Oct 1, 2014 5:16 PM, "Samuel Demirdjian" notifications@github.com wrote:
Hmm, I understand now what you mean @zombor https://github.com/zombor.
— Reply to this email directly or view it on GitHub https://github.com/kohana/database/pull/75#issuecomment-57480842.
When
Kohana Database will act as
But when
The SQL:
will run a fault.
So the change is When
The SQL will be: