After upgrade from 6.x-1.0 to 6.x-1.1 I'm getting this error when I leave the view field empty:

User warning: Column 'field_promoblock_view_vname' cannot be null query: content_write_record INSERT INTO ... etc.

I believe it is because of following change:

@@ viewfield_select_process($element, $edit, $form_state, $form) {
- '#default_value' => $element['#default_value']['vname'],
+ '#default_value' => isset($element['#default_value']['vname']) ? $element['#default_value']['vname'] : NULL,

Because in database definition, you don't allow vname to be NULL:

@@ function viewfield_field_settings($op, $field) {
case 'database columns':
      return array(
        // Views requires at least 96 chars for the view name and display, plus
        // we need 1 for our delimiter. Round up to a common value of 128.
        'vname' => array('type' => 'varchar', 'not null' => FALSE, 'length' => 128),
        'vargs' => array('type' => 'varchar', 'not null' => FALSE, 'length' => 255),
      );
CommentFileSizeAuthor
#10 1141200-column-vname-cannot-be-null-10.patch1.47 KBkeithm
#9 1141200-9_viewfield.patch1.16 KBwojtha
#6 1141200-column-vname-cannot-be-null-5.patch543 byteskeithm

Comments

keithm’s picture

keithm commented

The line in viewfield_select_process looks suspect to me also, but I can't reproduce your problem. I've just tried to break 6.x-1.0 and 6.x-1.x by leaving the view name field empty in a variety of ways, and I haven't been able to generate your error at all. Can you please provide steps to reproduce the problem you're seeing? Do you have any views enabled? Thanks.

wojtha’s picture

wojtha commented

I experience that during both Insert and Update. And yes I have several views enabled for the field.

It might be dependent on the used database/version or on specific setup. But in my case vname table column had NOT NULL property and if the viewfield was empty, I found NULL in the error query. In the previous version was there empty string '' instead of NULL.

I'm using MySQL 5.0.51a, Debian Lenny 64bit, Drupal 6.20.

keithm’s picture

keithm commented

In MySQL, your content type table (e.g., content_type_mytype) has a field_promoblock_view_vname'. That field's 'Null' property should be 'Yes' (or 1). (This is the same as 'not null' == 'FALSE'.) Is this setting correct in your database?

wojtha’s picture

wojtha commented

Nope I had "not null = TRUE" ~ NULL is disallowed. I changed NULL = NO to NULL = YES in the table when tried to fix the error yesterday.

So yesterday's config was:

FIELD                              TYPE              COLLATION       NULL
field_promoblock_view_vname        VARCHAR(128)      utf8_general_ci  NO

Hmm, strange. I will try to create new field and will see what happend.

And I was wrong with Drupal version. I'm not using Drupal but Pressflow (6.20).

wojtha’s picture

wojtha commented

Ha I found the bug.

The bug is in the update function:

function viewfield_update_6001() {
 // ...
        db_change_field($ret, $table_name, $vname_info['column'], $vname_info['column'], array(
          'type' => 'varchar',
          'length' => $new_length,
          'not null' => TRUE, // <<===== this should be FALSE
          'default' => '',
        ));
 // ...
}
keithm’s picture

keithm commented
StatusFileSize
new 1141200-column-vname-cannot-be-null-5.patch543 bytes

OK, I think I understand. New fields are being produced correctly but the schema upgrade process has a problem, so when you upgraded your database the 'Null' property was set incorrectly. Will you apply this patch and upgrade your database again please?

wojtha’s picture

wojtha commented

Best way to fix it will be probably rename viewfield_update_6001() to 6002 and fix the not null to FALSE. So the update will run on all installation no matter if the installation upgraded with 6001 update or not.

keithm’s picture

keithm commented

I'll think about that but will you confirm that this change fixes your problem?

wojtha’s picture

wojtha commented
Status: Active » Needs review
StatusFileSize
new 1141200-9_viewfield.patch1.16 KB

No it is not working if the 6001 is applied because of the length condition:

if ($vname_info['length'] < $new_length) {

I tried to modify it to this:

if ($vname_info['length'] < $new_length || $vname_info['not null'] => TRUE) {

But it doesn't work since in $vname_info contains values taken from Schema API and not real values from database schema. So I modify update to iterate over all fields. Alternate approach will be check for the real 'not null' schema property.

keithm’s picture

keithm commented
StatusFileSize
new 1141200-column-vname-cannot-be-null-10.patch1.47 KB

In #8 I was asking if the patch fixed the problem if the whole conversion process was redone. In that case 6001 wouldn't have run yet.

The 6.x-2.x branch already has a update_6002() so it must be accounted for.

wojtha’s picture

wojtha commented

No I have it "right" in #9 but I generated a reverse patch... I was lazy to use git which I usually use for patches, so I used only Netbeans IDE and swap the directions accidentally.

It might be handy to add comment why 6002 is missing.

I can confirm that the both patches in #9 (reversed) and in #10 is working.

keithm’s picture

keithm commented
Status: Needs review » Closed (fixed)

Fixed in http://drupalcode.org/project/viewfield.git/commit/738e96f.

chrisada’s picture

chrisada commented

I have already upgraded to 6.x-1.1 and am facing this problem. Could someone help point out how to fix my database? Thank you so much!

keithm’s picture

keithm commented

This problem is fixed in the development release 6.x-1.x-dev. Please try that and report back if it fixes your problem. I want some confirmations that this fixes the problem before issuing a new general release.

chrisada’s picture

chrisada commented

keithm, sorry I just has the chance to response. I faced the issue on a live site, and had to take immediate action. The only thing I did was manually editing the few viewfield fields and set NULL to yes, and everything works. If the changes you made in 6.x-1.x-dev includes that, it should fix problem for those who had upgraded from 1.0 to 1.1.

I don't have a backup of the database from when the problem still exist, so, sorry I couldn't help test this directly.

Thanks

dargrego’s picture

dargrego commented

I had similar problem and having upgraded 6.x-1.1 to the latest dev version, it disappeared, so it's working.
Thanks

stacysimpson’s picture

stacysimpson commented

@keithm, not sure if you are still looking for feedback on this thread, but we ran into this issue after upgrading to 6.x-1.1. The latest dev release, 6.x-1.x-dev (May 7 2011), resolved the issue after running DB update queries.

keithm’s picture

keithm commented

@stacysimpson Glad to hear this. Thanks.

sgerbino’s picture

sgerbino commented

6.x-1.x-dev also resolves the issue for my installation

roball’s picture

roball commented
Version: 6.x-1.x-dev » 6.x-1.1
Priority: Normal » Critical

I was also hit by this bug after upgrading from 1.0 to 1.1. Content that could be created without any problems under 1.0 may no longer be created under 1.1 - thus I am considering this bug as critical. Upgrading to 6.x-1.x-dev (2011-May-31) fixed the problem. IMO, 1.2 should be released asap. Thanks for consideration.

nterbogt’s picture

nterbogt commented

I'm also experiencing this issue and would like to see a new release sooner rather than later. It appears to have been fixed since the end of May, and has been two months.

In the meantime I'm planning to roll back to 1.0. I generally don't use development branches on my production servers.

roball’s picture

roball commented

I have opened #1229576: Please release Viewfield 6.x-1.2 to request a new official 6.x-1.x release.