You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fact, however, SqlKata generates the same SQL code from both queries:
SELECT*FROM
[Items]
As stated in the documentation, the Take method is merely an alias for Limit, so 0 is treated as “no limit.” Regarding Limit, this also makes sense from a linguistic point of view: zero limit = no limit. With Take, on the other hand, this is very misleading: take zero ≠ take everything
Changing the Take method to treat 0 as zero would, of course, be a fundamental change and a delicate one as well (and also a breaking change). But at the same time, it would make the API more precise and easier to understand.
You have a point here, this is a breaking change though, so worth discussing it further,
but for your use case, I would set a falsy where condition instead of limit, Limit() can be easily overriden, i.e. if you are wrapping your query with some logic to handle pagination, etc..., while this is not the case for .WhereRaw("1 = 0").
So my suggestion would be to always restrict your queries by a falsy where instead.
Activity
ahmad-moussawi commentedon Oct 31, 2025
You have a point here, this is a breaking change though, so worth discussing it further,
but for your use case, I would set a falsy where condition instead of limit,
Limit()can be easily overriden, i.e. if you are wrapping your query with some logic to handle pagination, etc..., while this is not the case for.WhereRaw("1 = 0").So my suggestion would be to always restrict your queries by a falsy where instead.
Note: be aware of top level or conditions though, anyway it's a bad practice to have top-level or conditions