At the moment, one might write
Users.where(email: email).count == 0 or
Users.where(email: email).count > 0
to check the existence of users with some email value, which is not an optimized way of doing that.
On top of that, the new Style/CollectionMethods RC rule would recommend writing those as Users.where(email: email).any?, Users.where(email: email).one? or Users.where(email: email).none?. However, none of those calls are actually optimized in Sequel, which will cause regression in the performance of those queries:
- as before, all the rows are being checked by the SQL engine (no regression here), but
- all the data fetched will now be transferred to the DB client, which can have real consequences in terms of performance.
From what I see, the proper way of performing those checks seem to be:
Users.where(email: email).empty?,
!Users.where(email: email).empty?, and
Users.where(email: email).limit(2).count == 1.
So, now that Style/CollectionMethods is enabled by default in RC, I think it would be appropriate to have these Sequel-specialized fixes before those generic (and possibly worse) rules to kick in.
Side note: I think it's an issue with Sequel's Dataset data model that it does implement the Enumerable API, but enables its methods perform non-optimized queries. I'm not familiar with Sequel enough to tell if this is intentional or not. 🤷
At the moment, one might write
Users.where(email: email).count == 0orUsers.where(email: email).count > 0to check the existence of users with some
emailvalue, which is not an optimized way of doing that.On top of that, the new
Style/CollectionMethodsRC rule would recommend writing those asUsers.where(email: email).any?,Users.where(email: email).one?orUsers.where(email: email).none?. However, none of those calls are actually optimized in Sequel, which will cause regression in the performance of those queries:From what I see, the proper way of performing those checks seem to be:
Users.where(email: email).empty?,!Users.where(email: email).empty?, andUsers.where(email: email).limit(2).count == 1.So, now that
Style/CollectionMethodsis enabled by default in RC, I think it would be appropriate to have these Sequel-specialized fixes before those generic (and possibly worse) rules to kick in.Side note: I think it's an issue with Sequel's Dataset data model that it does implement the
EnumerableAPI, but enables its methods perform non-optimized queries. I'm not familiar with Sequel enough to tell if this is intentional or not. 🤷