refactor: remove deprecations in Database

[paulbalandan]

Description
Removes deprecated items in database.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[paulbalandan]

After all the fixes to the tests, I realise now why they are failing. MySQLi\Connection relies on the deprecated $strictOn property from BaseConnection. This code block is now ignored:

if ($this->strictOn !== null) {
            if ($this->strictOn) {
                $initCommands[] = "sql_mode = CONCAT(@@sql_mode, ',', 'STRICT_ALL_TABLES')";
            } else {
                $initCommands[] = "sql_mode = REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(
                                    @@sql_mode,
                                    'STRICT_ALL_TABLES,', ''),
                                ',STRICT_ALL_TABLES', ''),
                            'STRICT_ALL_TABLES', ''),
                        'STRICT_TRANS_TABLES,', ''),
                    ',STRICT_TRANS_TABLES', ''),
                'STRICT_TRANS_TABLES', '')";
            }
        }

My question now is why are the tests look stricter without this? Are our tests not strict by default? Personally, I like the stricter tests I just fixed.

[neznaika0]

Use search
https://github.com/search?q=repo%3Acodeigniter4%2FCodeIgniter4%20strictOn&type=code
Has the functionality been migrated to mysqli yet?

CodeIgniter4/system/Database/MySQLi/Connection.php

Line 126 in a02639a

if ($this->strictOn !== null) {

[neznaika0]

Oh, you made it faster than me)

[paulbalandan]

I haven't added yet.

[neznaika0]

I realized that strict mode throws an error if we try to write a string of 11 characters in the varchar(10) field. In normal mode, this will just crop the text.

you can add a test for this?

With strict mode not set (default in version <= MariaDB 10.2.3), MariaDB will automatically adjust invalid values, for example, truncating strings that are too long, or adjusting numeric values that are out of range, and produce a warning.

[michalsn]

@paulbalandan

My question now is why are the tests look stricter without this? Are our tests not strict by default? Personally, I like the stricter tests I just fixed.

When $strictOn is set to false, framework explicitly removes strict SQL modes from the session. Ignoring this logic means connections now inherit the server default sql_mode, which in MySQL 5.7+ includes strict mode.

Code that relied on non-strict behavior (e.g., silent truncation, implicit numeric casting) may now receive SQL errors instead of warnings.

For compatibility reasons, we have to allow this mode, although I have nothing against changing it to true by default.

[paulbalandan]

Well, I have nothing against non-strict mode. For compatibility, yes, I would expect the framework to use non-strict mode but I'm annoyingly surprised the tests are not running strictly. IMO that's counter-intuitive to us promoting to use DBDebug as true but letting the DB driver swallow fatal errors.

Anyway, I'll open a PR to backport the fixes here to develop by turning $strictOn to true.

[github-actions]

👋 Hi, @paulbalandan!

We detected conflicts in your PR against the base branch 🙊
You may want to sync 🔄 your branch with upstream!

Ref: Syncing Your Branch