Has anyone seen problems where using table wizard to create a view makes other views disappear? Its happened on my site twice now but I'm still trying to figure out the pattern. I've got the view definitions in code on my system, but going to admin/build/views doesn't reload them into the database. It doesn't remove all views on the system. In one case, it only removed the views which had a display beyond the default display. I've tried fixing this problem by turning off views caching but that didn't help.

CommentFileSizeAuthor
#7 tw-558094-7.patch1.88 KBdarrellduane

Comments

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Postponed (maintainer needs more info)

Have you seen this since the initial report? Has anyone else seen it?

Thanks.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

What are the full symptoms? You don't see the views listed at admin/build/views, even after clearing the cache and making sure all the filter criteria at the top of the page are set to <All>, correct? If you try to access one of the missing views directly, does it come up?

Please check your PHP log. If there's no smoking gun there, you might try throwing in a return at the beginning of tw_views_default_views() (in tw.views_default.inc) to narrow things down - if you no longer have the problem in that case, try printing $views at the end of the function to make sure it's completing properly.

Thanks.

steve.m’s picture

steve.m commented
Status: Postponed (maintainer needs more info) » Active

I just noticed something that may be relevant to both this problem and some problems with views not being created for tables exposed to TW.

I was attempting to add two tables ('glossary' and 'glossary_versions') from an external database, and they consistently failed to appear in the views list or the views available to create content sets, etc. I haven't debugged very far, but it looks like this happens because there is some sort of namespace collision with the built-in 'glossary' view, which I just realized also disappears when they are added. Other tables added from this alternate DB (and that aren't named with the names of default views) were handled fine.

Schema 6.x-1.6
TW 6.x-1.1
Views 6.x-2.6

steve.m’s picture

steve.m commented

Quick follow-up: renaming the tables in the original db (to 'jvgloss' and 'jvgloss_versions') lets everything work as expected.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

OK, I haven't quite reproduced this symptom, but there's definitely some funkiness with namespace collisions. I'm going to need to dig into this some more, but I suspect the best I can do is prevent the creation of default views for tables which collide.

Thanks.

darrellduane’s picture

darrellduane commented

I'm dedicating some time to investigate this issue. I just added one of my tables to table wizard, and when I re-loaded the list of views at http://example.com/admin/build/views/list, 36 of my existing views disappeared, but 15 remained.
I also got this error at the top of the page in the red box which gave me the clue:

warning: array_merge_recursive() [function.array-merge-recursive]: recursion detected in C:\Drupal-6.14\includes\module.inc on line 473.

I looked further into this and found that the problem comes when there is an existing view name (in this case the name was students) that has the same name as the table name that Table Wizard imports. After removing the table from Table wizard, my views returned. After I removed the view named students from my list of views, and then added the students table to table wizard, there was no problem.

I should note that the existing view name named "students" is a view that is defined in a custom module and loaded with a call to hook_views_default_views().

I thought that we would be able to put something into table wizard that checks for the same existing view name and changes the TW view name slightly when creating the TW view if it finds one, but this strategy will not work because there can be other view names that get loaded by modules that come after 'tw' alphabetically. So, the solution I propose is that we prepend all view names created by table wizard with 'tw_', and truncate the end of the view name if it exceeds 32 characters.

If we do this we will also need to modify the Migrate module to look for view names in this format because there are some parts of the code where it directly equates the view name with the table name used for the source view.

Here is the patch code for doing this, note that it will break Migrate.

Thanks Mike for your help!

darrellduane’s picture

darrellduane commented
Status: Active » Needs review
StatusFileSize
new tw-558094-7.patch1.88 KB

Here is the patch. I've also added in some additional documentation in the description of the view, cleaned up a comment and ensured that the description doesn't exceed the maximum allowed space.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Needs review » Needs work

Yeah, migrate breaks all over the place. It's not just the map and message tables (the migrate default views hook can easily enough look for either the tw_ or plain version of the name), but existing content sets might be built on either tw default views (and thus need their view_name updated) or custom views (which should not have their view_name updated). Having reached the point with migrate where I've promised not to break anything (no update work needed beyond update.php), and reluctant to have migrate worry about whether it's working with a pre-fix or post-fix Table Wizard, I'd rather not do the global rename unless it's absolutely the only way.

So, how about a fix in the guise of a feature? In conjunction with #429130: Add option to disable autocreated views by default, when a default view is enabled for a table allow specifying the name of the view, with the table name of course being the default value. And, in tw_add_tables, check to make sure there are no existing views with the same name. I like this feature idea anyway - I prefer my content_set views to be named foo_content_set, and when it's just a single table it seems silly to create a custom view just to "rename" the default table view...

Thoughts? I'm starting work along those lines now...

Darrell, thanks for your work diagnosing this and coming up with an initial solution. I needed to see it concretely to really get thinking about the tradeoffs involved.

darrellduane’s picture

darrellduane commented

Hi Mike,
As I mentioned in the post above, and as you've also described, its not easy to find the names of existing views because of the way that views works. The particular problem I came across was because we define modules in a module name that begins with a 'u', and they don't get loaded until after the table wizard has defined its view.

So, I'm wondering if we should work towards submitting a bug (and bug fix) for the Views module to better handle the case when more than one view is defined with the same name? Perhaps if we came up with some cleaner way of that happening we could avoid having to deal with before and after case you describe above.

In any case, I feel like we need to update Migrate to better know what the view name will be for a given table name, no matter whether it is using an old version or a new version of table wizard. I believe we should be able to set something up without too much trouble that wouldn't break existing implementations.

Your thoughts?

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Assigned: Unassigned » mikeryan

Note that the Views UI prevents creating duplicate names there - also note that a UI-created view is considered an override of a default view with the same name (even if the shared name is an accident and the views have nothing to do with each other). So, the one prospect for conflicts is between default views. _views_discover_default_views() uses module_invoke_all(), which does an array_merge_recursive() of all results (and thus makes a hash of things when different modules provide default views with the same name). So, Views could replace module_invoke_all with a custom invoke that checks for collisions and throws out the second module's version and generates a message.

That would be helpful, but I still think the real solution on the Table Wizard end is to check for potential collisions when adding a table, and to support explicit view names. As you point out, migrate needs to stop assuming tablename==viewname, so as part of this work I'll add an API function tw_view_name($tablename). Migrate can handling pre-fix/post-fix with if (function_exists('tw_view_name')).

Thanks for your input.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Needs work » Fixed

OK, I've committed the feature to allow selecting an explicit view_name, and a corresponding change to the migrate module to check for the true view name...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

toby53’s picture

toby53 commented

Hi,
thanks!

I just ran into something unusual (just implemented a Acquia stack installation on my mac) where the first view I created was a table and its was not to be found on the Administer > Site Building > Views after that. After reading this post I first created view based on a list, then a view based on a table and both are now on the Administer > Site Building > Views. May have been my methods.