feat: add method to insert empty data in Model

[kenjis]

Description

• add Model::allowEmptyInserts() to insert empty data

Checklist:

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

[kenjis]

It seems OCI8 driver can't get the insert id.

1) CodeIgniter\Models\InsertModelTest::testInsertPermitInsertNoData
Failed asserting that a row in the table [insert_no_data] matches the attributes 
{
    "id": 0
}

Found: [].

/home/runner/work/CodeIgniter4/CodeIgniter4/system/Test/DatabaseTestTrait.php:280
/home/runner/work/CodeIgniter4/CodeIgniter4/tests/system/Models/InsertModelTest.php:220

https://github.com/codeigniter4/CodeIgniter4/runs/6840259577?check_suite_focus=true

[iRedds]

I saw on a forum or a github issue that someone came across the inability to use an empty request.
In my opinion, this is due to the problem of database design, since in my opinion the table for the test in PR does not make logical sense without links to other tables and containing only auto-increment and timestamps.

The solution is to use a raw query or add a tinyint(1) column with arbitrary data.
It seems to me that adding just such functionality is not rational.

[kenjis]

In my opinion, this is due to the problem of database design, since in my opinion the table for the test in PR does not make logical sense without links to other tables and containing only auto-increment and timestamps.

It makes sense if it has links to other tables.
For example, imagine that is users table, and all other user's attributes are stored in other tables.

[iRedds]

I wrote about links with other tables.
But what's the point of creating an empty record in the dependent table.

You either add data or you don't.
I can't imagine a case where it makes sense to add a record without data.
Maybe I don't understand something?

[kenjis]

It is not to add a record without data. The record will have ID.
But just insert data is empty.
If you add timestamps to columns by the field default value, the record will have timestamps, but the insert data is empty.

The point is sometimes we need this functionality to avoid "no data to insert" exception of Model
It may be because of bad design for tables, but we don't say it is always because of bad design.

[iRedds]

The table consisting of (id, created_at, updated_at) seems strange to me.

[MGatner]

I like this feature. Some implementation suggestions and requests.

[MGatner]

Consider naming after the existing properties.

Suggested change

	protected bool $prohibitInsertEmpty = true;
	protected bool $allowEmptyInserts = false;

[kenjis]

Done.

[MGatner]

The table could have any amount of data from default values. If a developer wants to let the database handle those, as it stands currently you need to submit some "dummy" data. I think our protections in general are good but I am a fan of the option to override those protections when needed.

Example based on kenjis:

TABLE users
PRIMARY KEY id
TIMESTAMPS created_at, updated_at
FIELD role DEFAULT 'user'
FIELD active DEFAULT 0

TABLE emails
PRIMARY KEY email
TIMESTAMPS created_at
FOREIGN KEY user_id

This fails:

$id = model(UserModel::class)->insertReturnId([]);
model(EmailModel::class)->insert([
    'user_id' => $id,
    'email' => '[email protected]',
]);

[kenjis]

@ytetsuro Can you debug this? It seems only Oracle can't get the insert id.
#6109 (comment)

[ytetsuro]

@kenjis

Ok!
I will check it!

[ytetsuro]

@kenjis

This test is lose the database error message.
You can’t understand why fail.😭

I fixed it.👍

#6113

[kenjis]

@ytetsuro Thank you so much!
I was wondering if there was some bug in getting the insert id.

[MGatner]

I would like to hear if @iRedds has any other thoughts before we move on from the discussion.

[kenjis]

I think if we support insertion of empty data, Query Builder should support it.
The query is not unified.
See https://github.com/codeigniter4/CodeIgniter4/pull/6109/files#diff-1a690370bdbdc5997068f9ff210bacef314eeb65d1df73af206783ce055d8d1dR280

[MGatner]

Looks good!

[MGatner]

@kenjis Your diff link doesn't work for me on mobile so I'm not sure what the issue is in Query Builder, but I am fine with adding a parallel feature there.

[kenjis]

@MGatner Sorry, I didn't explain what the issue is in Query Builder.
The link just shows there are three types of queries to insert no data.

Query Builder also prohibit inserting no data.
$builder->insert([]) does not work, an exception is thrown.

[kenjis]

Rebased and added the documentation.

@iRedds Any comments?

[MGatner]

My only thought on the docs is maybe to mention an example of why one might want do this.

[kenjis]

Resolved conflict.

[kenjis]

Sorry, I made a mistake when I rebased.

I mistakenly rebased with develop first and then rebased with 4.3.
So this PR contains commits from develop that have not yet been merged into 4.3.

[MGatner]

Shouldn't be a problem, develop => 4.3 should handle that after next patch release.

[kenjis]

Okay, thanks.
Since revert does not make much sense, leave it as it is.

develop => 4.3 should handle that after next patch release.

No, it is daily job.
I generally do it once a day.

If we do not merge, bugs will remain unfixed in 4.3, and conflicts are likely to occur as the difference between develop and 4.3 grows. So it is better to merge continuously.

[MGatner]

If that becomes tiresome we could set up a GitHub Action to merge to 4.3 anytime develop is updated. I'd be willing to look into that.