[dev] [commits] Horde branch develop updated. 9479c9cecf80727cc1f18cfe99ab17284f86402d

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>>>
>>>>> commit 9479c9cecf80727cc1f18cfe99ab17284f86402d
>>>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>>>> Date:   Sat Jul 7 15:38:11 2012 -0400
>>>>>
>>>>> Ensure we have a default value.
>>>>>
>>>>> Possible fix for Bug: 11246
>>>>>
>>>>> wicked/migration/4_wicked_single_revisions.php |    8 ++++----
>>>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> http://git.horde.org/horde-git/-/commit/9479c9cecf80727cc1f18cfe99ab17284f86402d
>>>>
>>>> We probably should catch that in Horde_Db too.
>>>
>>> I thought of that, but wouldn't that prevent ever having a true  
>>> NOT NULL column that actually enforces having to pass a non-null  
>>> value to the database? I.e., it's conceivable that some code would  
>>> want the database tier to reject a record if it doesn't contain a  
>>> non-null value for some field. Handling this in the Horde_Db layer  
>>> would prevent this. At least as it is now, if we wanted to reject  
>>> a null value instead of assuming it's '0' or '' or whatever, we  
>>> could perform another alter table action that edits the column  
>>> after the migration logic is complete.
>>
>> We wouldn't be able to use that feature anyway, if we cannot even  
>> create a portable database scheme that enforces this. This might be  
>> irrelevant for 3rd party developers using Horde_Db and never  
>> planning to do anything with SQLite though. It's a trade-off.
>
> This is only an issue, AFAICT, when adding a new column to a table  
> with existing data. If no default is given the values are null, but  
> it is not noticed until we try to update a row. It's not really that  
> SQLite cannot enforce the NOT NULL, it's just that it is only  
> noticed when we manipulate/add a row. So we can enforce it, but not  
> when adding new columns during migrations.

Ah, I see.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/