SQL error after migration from views bookmarks 5.x-1.4

flag_content_fav_bookmark.vbid

Views tries to pull-in a "vbid" field. In "Views Bookmark 1.4" there's indeed a "vbid" field: it's the "Bookmark: Ops for Bookmarks" field. CoolDreamZ, do you parhaps remember if you had these "Ops" on your view? ("Ops" are the bookmark/unbookmark links).

This field was later renamed, in "Views Bookmark dev", to "ops".

So you should have first gotten rid of this "vbid" field by upgrading to "Views Bookmark dev", before migrating to Flag. Of course I don't blame you for not doing this ;-)

Hmmm....

Nate, I think there are three options here:

1. We could release a "Views Bookmark 1.5" and tell people to upgrade to it before migrating to Flag; or:
2. Since we can't guarantree our migration code doesn't fail, we can give our users general instructions for fixing problems: "If your view generates SQL errors, go to its edit page; Open all fieldsets: if a field/filter didn't migrate correctly you'll see an empty line in stead. Simply delete this field/filter and insert it anew."

   CoolDreamZ, could you try to apply these "general instructions for fixing problems" and report back? (But perhaps Nate would want to ask you some questions first. So it's better to wait a bit.)

   or:

3. In flag_views_bookmark_update_views() we could rename all "vbid" fields to "ops", by changing:
   

   foreach ($view->$view_portion as $delta => $individual_piece) {
   

   to:

   foreach ($view->$view_portion as $delta => $individual_piece) {
     if (isset($individual_piece['field']) && $individual_piece['field'] == 'vbid') {
       $view->{$view_portion}[$delta]['field'] = 'ops';
       $view_changed = TRUE;
     }
   

   (code not tested.)

I'm in favor of option #2, the "general instructions". But I also think we should release a "Views Bookmark 1.5".

CoolDreamZ, could you try to apply these "general instructions for fixing problems" and report back? (But perhaps Nate would want to ask you some questions first. So it's better to wait a bit.)

But already you can execute half of these instruction: go to you view's edit page and see if you have 'empty' line(s) in the fields or filters or arguments sections. You should see only one such line: where your "Ops" field used to be. Let me know if that's what you see. Don't yet modify your view.

I have two new ideas:

1. You should be able to export your view. Please do that, paste it to pastebin.com, and paste here the link.

2. You can clone your view and apply the "general instruction" to the clone.

array (
'tablename' => 'flag_content_fav_bookmark',
'field' => 'vbid',
'label' => 'Remove Favorite',
),

Yes, so it was the Ops field. I'll probably open a separate issue.

I now get a new SQL error

(I'm investigating this.)

CoolDreamZ,

The short answer: clearing Views' cache will probably solve this problem (there's a 'clear' button at ?q=admin/build/views/tools).

let us know if it doesn't solve your problem.

I also get the same (new) SQL error if I create the view from scratch (but without re-creating the bookmark/flag type)

(I'm cusrious if you meant to say: "It only happens to existing flags. New flags work alright." I assume it's not what you meant to say.)

The long answer:

That's an interesting problem. Your first query in this issue has:

LEFT JOIN flag_content flag_content_fav_bookmark
ON node.nid = flag_content_fav_bookmark.content_id
  AND flag_content_fav_bookmark.fid = '2' 

But your current one has:

LEFT JOIN flag_content flag_content_fav_bookmark
ON node.nid = flag_content_fav_bookmark.content_id
  AND flag_content_fav_bookmark.fid 

The current one is missing the final " = '2'". On the one hand $flag->name is known ('fav_bookmark'), but on the other hand $flag->fid (2) isn't known. That's weird. That's what eventually leads to the 'flag_types_.type' problem as well. I can't think of an explanation for this, and for the meantime I'll assume this is something users of this module aren't likely to encounter. (If the 'clear' button doesn't solve your problem, I'll change my mind.)

It turns out most of what I wrote in comment #2 wasn't correct:

This module *does* know to migrate the Ops pseudo field from VB 1.4. It's just that there was a typo that prevented this migration from hapenning. I fixed this.

So the only problem left here is the "new SQL error" (comment #7). I'm marking this "needs more info": I need to know if the "clear cache" button solves it.

user warning: Column count doesn't match value count at row 1 query

This has been fixed already, here. Sorry for the bother. I've asked Nate about creating a 'dev' release to solve this problem.

===

So we're left with error #7.

Error #7 was when I edited the existing view and removed/replaced the flag ops

1. It doesn't happen on new views?

2. Could you give me the output of the following command?

views_load_cache();
$table_data = _views_get_tables();
print_r( $table_data['flag_content_fav_bookmark'] );

This will tell us exactly how Views sees this table.

(You seem like a 'power user', that's why I feel I can ask you to execute some code. The 'devel' module makes this simple. But it's ok if you can answer only my first question.)

I do have devel installed however, after hunting around, I can't see where to enter/execute the code.

Devel has an 'Execute php' block you can enable and put, e.g., in your footer. Go to the the blocks administration page and enable this block there (I don't remember the block's name but it won't be hard to recognize it).

Thanks for the output.

Array
(
    [name] => flag_content
    ...
            [extra] => Array
                (
                    [fid] => 
                )
   ...
   [filters] => Array
        (
            [uid] => Array
                (
                    [name] => Flag: Fav Bookmark
                    ...
                    [fid] => 

That's what I suspected: the 'fid' slots are all empty. It's a mystery, because other properties of the flag, e.g. $flag->title (which is "Fav Bookmark"), do get seen.

Could you please give me the output of the following code?

print_r( flag_views_tables() );

Thanks. That new output shows that the problem isn't in Views but in the database.

I have a good guess: the table 'flag_types' doesn't contain the node-types this flag applies to.

Could you please give me the output of "SELECT * FROM flag_types" ? If my guess is correct, we won't see there records whose 'fid' column equals '2'.

OK, I think we've finished here.

The module could not load flags that weren't associated with some node-type. That caused your problem(s). I fixed that.

You'll now (after downloading the 'dev' version) be able to edit this 'Fav Bookmark' flag: the first thing you should do is to associate it with some node-type(s), because this module can't handle 'orphan' flags.

The next thing you should do is clear Views' cache (there's a 'clear' button at ?q=admin/build/views/tools).

This should fix all your problems. If it doesn't, re-open this issue.

Notes:

1. You'll have to download the 'dev' version, as it contains the latest fixes. But the server packages it only once in a while (once a day?), so you'll have to wait a few hours (or download via CVS).
2. I don't know what caused that flag to be saved without associated node-types in the first place. I'll assume it was a problem derived from bugs already fixed.

Thanks a lot for your feedback, you've helped to make the module better.