Do you use Query Builder Caching?

In the Query Builder, you can cache parts of the query to reuse in the following query, as explained in the user guide. Someone recently brought up the idea of getting rid of that for CI4, since the Query Builder is now a standalone class, and they could just clone the object to get another instance to use if they needed, allowing the Query Builder code to be simplified by removing the caching.

To be honest, I've never used the QB caching before, so I'd love to hear how you use it, maybe even with examples, to see if this is a change that would make sense or not.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

Database caching is very useful, but caching only the query string is useless... I've never used it and can't imagine a real life use case. The performance benefit is insignificant and it makes the code harder to understand.

Just drop it ... I'd drop it from 3.x if it wasn't a BC break, but you don't have that problem.

Just drop it ... I'd drop it from 3.x if it wasn't a BC break, but you don't have that problem.

Sounds like a plan then.

I couldn't figure out a use case for it anyway, honestly, and like orionstar said - just makes the code harder to understand.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

Just drop it ... I'd drop it from 3.x if it wasn't a BC break, but you don't have that problem.

Sounds like a plan then.

I couldn't figure out a use case for it anyway, honestly, and like orionstar said - just makes the code harder to understand.

There are a few, but nothing you can't do otherwise and it turned out to be a maintenance hell, so totally not worth it.

I already gave my opinion on it
I used it only a few times especially when I needed to fetch a limited set of data and then count the full result set with an almost identical query (eg for datatables server side), but with the possibility of cloning this shouldn't be an issue anymore.

In the Query Builder, you can cache parts of the query to reuse in the following query, as explained in the user guide. Someone recently brought up the idea of getting rid of that for CI4, since the Query Builder is now a standalone class, and they could just clone the object to get another instance to use if they needed, allowing the Query Builder code to be simplified by removing the caching.

To be honest, I've never used the QB caching before, so I'd love to hear how you use it, maybe even with examples, to see if this is a change that would make sense or not.

Sorry for the English, but it's a translation.

I hope it's not too late,

I'm going to give you a case of use, all my models extend to a class that I believe in core / SCE_model and SCE_Model extends to CI_Model, the case is as follows.


When I have to do a GRID to present data to draw, paginate and filter data, what I do is the following, suppose that it is for users the grid that I am going to work on.
I have a method in SCE_Model called get_data_grid (); that I use it in all my models

$ this-> db-> stop_cache ();

------------------- HAVE THE AMOUNT OF RECORDS -------------------------- ----------------
$ this-> db-> select ('count (*) as total_records');
$ this-> total_records = $ this-> db-> get ($ this-> table_name) -> row () -> total_records;
-------------------------------------------------- -------------------------------------------------- ----------------

------------------------------------ THIS PAGINATING YOU THE GRID -------- ---------------------------

$ this-> db-> limit ($ limit, $ start);
$ this-> db-> get ($ this-> table_name) -> result ();
-------------------------------------------------- -------------------------------------------------- ----------------


So these 2 queries keep the same criteria: where, or_where, where_in, like, or_like, where_in, group_by you know that this is a subject when a grid is made to maintain the pagination and filters.

So from my example model users I only do the following


$ this-> db-> start_cache ();
$ this-> db-> select, where, or_where, where_in, like, or_like, where_in, join .... And so on
And atomically the 2 query already has the same criteria

$ this-> get_data_grid (); // THIS METHOD IS THE SCE_Model that all the models use and it adapts to the table that I say $ this-> table_name.

I have used QB caching for the same reasons as @henry.polanco.r described above - an ad hoc set of filter conditions to be paginated.