Closed (fixed)
Project:
Drupal driver for SQL Server and SQL Azure
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
6 Oct 2015 at 19:14 UTC
Updated:
4 May 2016 at 15:07 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
dobe commentedComment #3
dobe commentedI am not seeing an issue with Webform's code here. I think it is a SQLSRV driver issue.
Comment #4
dobe commentedBack to webform.
According to: https://api.drupal.org/api/drupal/includes!database!database.inc/functio...
I believe We need to set an "initial" value in the specifications. There are places in the webform.install but for some reason it was not being done anymore. Patch shortly to address this.
Comment #5
dobe commentedComment #6
dobe commentedComment #7
dobe commentedComment #8
danchadwick commentedThis doesn't look right to me. It looks like a bug is the MSSQL driver.
Here's the MySQL version:
https://api.drupal.org/api/drupal/includes%21database%21mysql%21schema.i...
From db_add_field (emphasis mine):
This should only be needed when there is NOT a default, but all the instances changed in the patch do have a default. What's the MS code look like?
It would be a performance hit to add initial unnecessarily.
Comment #9
dobe commentedI was leaning towards that at the beginning. The code in the sqlsrv is slightly different to mysql as it does this:
But your right. I feel there is kind of multiple ways to take the statement on the docs: $spec: The field specification array, as taken from a schema definition. The specification may also contain the key 'initial', the newly created field will be set to the value of the key in all rows. This is most useful for creating NOT NULL columns with no default value in existing tables.
Comment #10
dobe commentedSQLSRV seems to double up it's effort's in these functions. I am guessing the problem would exist in both scenarios. The mysql version consolidates the last part of addField and runs changeField on it so I am not sure exactly why there is all the comments within this function about
As it appears based on the mysql code that it has the same issue hence passing the data to changeField function.
Comment #11
dobe commentedComment #12
danchadwick commentedBingo. The PHP function empty() does not do what many developers think it does. Unfortunately, it is frequently used within Drupal when the value is very unlikely to be "0", such as in a user-entered name. Drupal core is filled with these small bugs.
http://php.net/manual/en/function.empty.php
Your patch will also address the bug when the default is the empty string, as well as a float 0.0.
Comment #13
mattlc commentedHi,
tested #10 : It does the job.
Before this patch (only #10), i could not manage to install various critical modules such as ds, block_class and even UUID.
Hope this will be released soon.
It would be great if the patch could be applied to root dir instead of includes/database, but I can wait for release...
Thx.
Comment #14
dobe commentedGreat if you could mark as Reviewed and Tested that would be great. The patch is applied from a cloned version of the module. So I am not sure about the remark:
Thank you!
Comment #15
mattlc commentedSee #13.
@dobe, don't worry about that misunderstanding.
Comment #16
david_garcia commentedThis thing needs tests. I can't believe those default values were broken!
Comment #17
mattlc commentedHope this help.
@DanChadwick seems to be right. "empty" cause problematic behavior with non empty tables when adding column not null with empty default value.
I tried all available versions and ended with this "stronger" test :
"!empty($spec['not null']) " becomes "isset($spec['not null']) && $spec['not null']==TRUE"
With default collation set to recommanded "Latin1_General_CI_AI".
It seems to be OK.
Comment #18
mattlc commentedComment #19
danchadwick commented@mattlc -- what distinction are you making between:
$spec['not null']and$spec['not null']==TRUE?While the PHP rules for
==are convoluted, I'm pretty sure that not_null will always be a boolean or a truthy value. I think the best code for checking a boolean such as this is!empty($spec['not_null']). This will be true for TRUE, any integer other than 0, any string other than "" or "0".For example, your code would not be TRUE for 1, and I'm pretty sure if you set non_null to 1, you mean for the field to be not_null.
Comment #20
mattlc commented@DanChadwick
You are right.
I just tested this code :
And it gives
So why UUID (and other modules defining shema with empty not null colmuns in non empty tables) can be installed with
$spec['not null']==TRUEand not with !empty($spec['not null']) ?Comment #21
virusakos commentedI have tried patch #10 with the following modules (I'm not sure which of them are altering the tables with a not null column)
Everything works ok up to now.
Comment #22
david_garcia commentedComment #23
joseph.olstadWe've been successfully using patch 10 in our dev environment since Oct 23 2015. Applied over the latest 2.x dev version of sqlsrv.
Comment #24
tim.plunkettComment #26
david_garcia commentedComment #27
amleth2 commentedIs the recommended collation for the SQL server database now Latin1_General_CI_AI, and not SQL_Latin1_General_CP1_CI_AS as per http://www.drupalonwindows.com/en/blog/installing-drupal-windows-and-sql...?
Comment #28
david_garcia commented@amleth CI_AI is the recommended, because binary comparison (CS_AS) is an explicit option at the column level in Drupal.