Ezp 16509 changing db default values

[pkamps]

Why this patch?

When editing a content class, you can define a default value for the datatype ezinteger. You cannot remove the default value: as soon as you save the class changes with a Null value for the ezinteger default value - the system will store the '0' number for the default value.
In other words, when editing content object for this class, you cannot have a null value for the ezinteger attribute. But it makes a difference if the attribute value is set and '0'. Or if the attribute value was not set and Null.

Background
The default value for ezinteger attributes are stored in the DB table ezcontentclass_attribute. It uses the data_int3 field.
The database table to store class attributes (not object attributes) allows null values for all data_int and data_float fields - Default column is set to 'Null':

mysql> describe ezcontentclass_attribute;
+-----------------------------+--------------+------+-----+---------+----------------+
| Field                       | Type         | Null | Key | Default | Extra          |
+-----------------------------+--------------+------+-----+---------+----------------+
| can_translate               | int(11)      | YES  |     | 1       |                |
| category                    | varchar(25)  | NO   |     |         |                |
| contentclass_id             | int(11)      | NO   | MUL | 0       |                |
| data_float1                 | double       | YES  |     | NULL    |                |
| data_float2                 | double       | YES  |     | NULL    |                |
| data_float3                 | double       | YES  |     | NULL    |                |
| data_float4                 | double       | YES  |     | NULL    |                |
| data_int1                   | int(11)      | YES  |     | NULL    |                |
| data_int2                   | int(11)      | YES  |     | NULL    |                |
| data_int3                   | int(11)      | YES  |     | NULL    |                |
| data_int4                   | int(11)      | YES  |     | NULL    |                |
| data_text1                  | varchar(50)  | YES  |     | NULL    |                |
| data_text2                  | varchar(50)  | YES  |     | NULL    |                |
| data_text3                  | varchar(50)  | YES  |     | NULL    |                |
| data_text4                  | varchar(255) | YES  |     | NULL    |                |
| data_text5                  | longtext     | YES  |     | NULL    |                |
| data_type_string            | varchar(50)  | NO   |     |         |                |
| id                          | int(11)      | NO   | PRI | NULL    | auto_increment |
| identifier                  | varchar(50)  | NO   |     |         |                |
| is_information_collector    | int(11)      | NO   |     | 0       |                |
| is_required                 | int(11)      | NO   |     | 0       |                |
| is_searchable               | int(11)      | NO   |     | 0       |                |
| placement                   | int(11)      | NO   |     | 0       |                |
| serialized_data_text        | longtext     | YES  |     | NULL    |                |
| serialized_description_list | longtext     | YES  |     | NULL    |                |
| serialized_name_list        | longtext     | NO   |     | NULL    |                |
| version                     | int(11)      | NO   | PRI | 0       |                |
+-----------------------------+--------------+------+-----+---------+----------------+

The problem is the PHP wrapper class for this DB table:
48a01e5

It uses the default value '0' for those fields. So if you try to save a 'Null' value for data_int3, ezpublish will replace it with the value '0'.

3 commits
I divided the patch into 3 commits on purpose.

1. the first commit is changing the DB wrapper PHP class
2. The input validation was broken for ezintegers and I changed the input validation for ezstrings.
3. Only changing the code format. No need to review it in details.

Risks
This patch is affecting all class attributes (not object attributes) - not only ezinteger. There is the risk that this patch introduces issue for other class attribute definitions (if they use the DB fields data_intX/data_floatX).

[pkamps]

The 4th patch was needed to resolve a conflict.

[pkamps]

Fifth patch is to make the unit tests happy.

[peterkeung]

As I understand it, the problem is that you cannot remove a default value for an Integer field type. I have experienced this problem.

What is the more concrete editorial use case? The editor should be able to store a blank value? We need to force the editor to enter a value but the default of "0" means they can get away with not entering something? Is an alternative to override the edit template for that datatype? (Not ideal, but just want to understand the use case fully.)

If we proceed with the patch, how do we check whether other field types using data_int3 are affected?

[pkamps]

I think you got it already. It makes a difference if the value is 0 or null (nothing entered by the editor). Quick example:
Editors daily create content objects to store weather information like the temperature. On some days the the thermometer is broken and the editor does not want to enter a value. He/She cannot do it. That day it will be zero degrees in the middle of the summer...

[pkamps]

How we check weather other fields type are affected

We cannot guarantee it. The only things to improve the situation are:

• make sure that unit tests passes (very unlikely that it covers every aspects of the datatypes)
• I added a new branch release/alpha - we could use that branch to test more risky patches like this one - not sure if there any guinea pig out there

The risk is limited to the editorial experience and won't affect already stored data - so that's a lot less risky. For example the ezstring datatype has a max char configuration. That's a potential feature that could break.

[pkamps]

Test on CSM. Report back. Decide later if we'd like to merge it.