[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>:
>>
>>> 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.

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