CodeIgniter 4 Proposed Roadmap

can't wait for CI4!
a revolution for CI, i think.
I think this is a good idea to have an ORM in CI4 like eloquent in laravel.

You can include Eloquent in Codeigniter via composer and about 10 lines of code.

Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!

Is there a good reason not to use HMVC?

A very good question :-).
But if the core modules will be truly independent, you probably can simply overwrite several features to easily get HMVC. I hope.

What are you thinking for the Database Layer?

Right now it's kind of a mess, with a lot of outdated drivers.

It seems like the best course of action would be to use PDO as the starting point, and add back drivers around that.

At the very least, you're going to have to remove the original mysql driver, as the mysql_ family of functions is finally gone from PHP 7.

What are you thinking for the Database Layer?

Right now it's kind of a mess, with a lot of outdated drivers.

It seems like the best course of action would be to use PDO as the starting point, and add back drivers around that.

At the very least, you're going to have to remove the original mysql driver, as the mysql_ family of functions is finally gone from PHP 7.

The code is available to look at

Honestly, it will remain similar to how it has been with both PDO and non-PDO drivers. We currently have MySQLi and PostgreSQL drivers implemented. Others will be looked at to see current status, if it's possible to get it actually tested in Travis, etc.

PDO has some great benefits, and many frameworks go that route but here's a couple things to consider. Not all PDO versions of the drivers have all of the same features as their non-PDO versions, so you could be missing out if you really need to get down to brass tacks with your database if you're using the PDO version. Granted, it won't crop up much, but discrepencies do exist.

Furthermore, what does PDO do? Primarily two things: it provides a consistent way to connect to the various databases. That's it's primary reason for being. A lot of people bring up prepared statements as the reason to use. A number of the non-PDO drivers also support that feature so that's kind of a wash.

Either way, the driver that CodeIgniter has always taken care of both of those points with all of the different drivers that it supports. It doesn't do prepared statements exactly, but has always escaped the data to keep it safe. Yes, I know prepared statements are still a bit more secure since the variables are sent in a completely different format than the query itself. Another good thing to be aware of is that use of prepared statements for every call doubles the strain on your database, potentially causing your app's performance to suffer, which is the exact opposite of what prepared statements were intended to do for you.

But, that mini-rant aside, we will continue to provide PDO support across a variety of databases for those that prefer to use it. We also now support true prepared statements for those times when you feel the need for speed.

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

A lot of people bring up prepared statements as the reason to use. A number of the non-PDO drivers also support that feature so that's kind of a wash.

I'm writing this from PostgreSQL's perspective.

The most important aspect of query parameterization is that if done properly, it prevents SQL injection type of attacks without requiring the developers to reinvent data-sanitizing procedures based on quoting and escaping (either client-side and therefore error-prone or server-side and therefore adding more round trips).

In most DB drivers, query parameterization is implemented either by using server-side prepared statements or by emulating them at client-side by replacing placeholders with their corresponding values. The former is suboptimal most of the time (one command is sent to prepare a statement, one to execute it, and sometimes - like in PDO - another one to deallocate the prepared statement). The latter is just unsafe.

The official Postgres client library, libpq, provides a convenient function PQexecParams(). It issues only one command to a server, sending a query string with placeholders and values separately, so the values will never have a chance to affect how the query is interpreted by the server.

In the reference PHP implementation, PQexecParams() is used internally under the hood of pg_query_params() (unconditionally) and PDOStatement::execute() (conditionally). The condition for PDOStatement::execute() to use PQexecParams() is that the option [PDO::PGSQL_ATTR_DISABLE_PREPARES => true] has to be passed either to PDO::__construct() (making it a per-handle setting) or to PDOStatement::prepare() (making it a one-time setting). By default PGSQL_ATTR_DISABLE_PREPARES is set to false, so PDO will use server-side prepared statements, which is a great feature but only when many executions of the same query with variable parameters are done. Using server-side prepared statements for single query execution is just crippling performance.

By not using pg_query_params() for query parameterization CodeIgniter leaves its users PDO as the only way of having easy, safe and performant protection from SQL injection type of attacks in a CodeIgniter-based application. Which is unfortunate, because PDO itself has the sad restriction that the question mark character is always interpreted as a placeholder, so it's impossible to use it in a query string literally as anything else than a placeholder (as in "SELECT 'a=>1,b=>2'::hstore ?| ARRAY['b','c']", for example). The restriction can be worked around, it probably can be even fixed in PDO, but for the time being, pg_query_params() would be my preference for query parameterization implementation.

To make things worse, when _protect_identifiers is true (the default), CI_DB_query_builder as of version 3 will try to escape string parameters with pg_escape_literal() regardless of whether it's actually needed or not. This adds another unnecessary round trip whenever PQexecParams() is used, because strings can be safely passed verbatim in that case.

With regard to CI_DB_query_builder, I'm not 100% sure if my understanding is correct - please tell me if it isn't. I forgot to add this to my previous post and now can't edit that, because it's pending moderation.

Hey pstef, you obviously have much more technical understanding of Postgres than I do. We welcome pull requests if you can find a way to improve the current implementations.

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

We welcome pull requests if you can find a way to improve the current implementations.

That would probably require a rewrite of the query builder and it wouldn't be compatible with the current one. I'll probably write my own for my own uses and purposes.

is this still happening?

If by "this" you mean v4, then yes.

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