[5.7] Implemented having between

[BrokenSt0rm]

In the past few weeks we needed to do an having between at work.
We found out that Laravel only supports this type of having with a raw clause, so I'm submitting this PR to help anyone that have our needs and do not want to write a raw clause.
It does not affect the way havings are built so it's a non breaking change.
I have included some basic tests.

[mfn]

On which databases did you test this?

Are we sure it works on all supported databases (mssql,mysql,pgsql,sqlite) that way?

[BrokenSt0rm]

The having clause with the between operator is valid on all databases that Laravel supports.
I have tested this syntax on all of them.

[taylorotwell]

Why is this needed?

[BrokenSt0rm]

It was for my initial implementation, I'm removing it right now.

[taylorotwell]

Why is this needed?

[BrokenSt0rm]

It was for my initial implementation, I'm removing it right now.

[BrokenSt0rm]

Removed, sorry. My mistake.

[nanaya]

Just want to say HAVING in postgres and sqlite3 (and maybe more?) turns the query into grouped query.

// postgres
mydb=> select * from users having id between 10 and 20;
ERROR:  column "users.id" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: select * from users having id between 10 and 20;

// sqlite3
SQLite version 3.25.1 2018-09-18 20:20:44
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table users (id integer);
sqlite> select * from users having id between 10 and 20;
Error: a GROUP BY clause is required before HAVING
sqlite>

Also HAVING ... BETWEEN query doesn't use index in mysql (except in rare cases).

[test]> create table users (id int, email varchar(255));
Query OK, 0 rows affected (0.67 sec)

[test]> create index users_id on users(id);
Query OK, 0 rows affected (0.62 sec)
Records: 0  Duplicates: 0  Warnings: 0

[test]> explain select * from users having id between 1 and 10;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | users | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

[test]> explain select * from users where id between 1 and 10;
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | users | NULL       | range | users_id      | users_id | 5       | NULL |    1 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.01 sec)

There's WHERE ... BETWEEN which actually works everywhere (and uses index).

[mfn]

That was my fear. Seems a lot of edge cases to be aware for this feature.

I get the feeling this is better left for users who need it and just should use any *raw* variant and do it themselves then having this integrated and working problematic.

TL;DR: I'm in favour of removing it.

[BrokenSt0rm]

@nanaya @mfn

It's obvious that you have to use a group by in combination with an having clause, and obviously you must select only fields used in grouping clause, not select *.
The where between can't be used when you have to filter after a group operation, which was our case in my company, because where clauses are applied before the grouping operation, it's not a solution.
Only MySQL will not comply with the query provided because it's more flexible in this case, but that query makes no sense at all.
Following that thinking line, we should remove also having method because that errors would still show up.
When you use a database you must know how it works, an ORM like Eloquent don't make any changes to this assumption.

[nanaya]

I only mentioned it because the wrong example query made it to laravel news page.