adopting a table without a primary key doesn't create a corresponding view

Enable the data_ui module. You'll get one view per data table.

If thats the case, then there is a bug. If I create a table using the data module, then I have a view for that table. If I adopt a table, I don't get a view.

Marking as active and changing to dev since its and issue w/ that as well as alpha.

I also tried: http://drupal.org/node/1412014#comment-5697626 to get my configure views to work... but that hasn't helped.

Ok, so let's retitle this.

I don't think I've looked *at all* at the code for table adoption since becoming a co-maintainer, so any help with debugging / writing patches would be much appreciated :)

When I adopted a table the following errors were reported.

Warning: array_keys() expects parameter 1 to be array, null given in data_search_get_fields() (line 189 of /home/kbailey/projects/icmsv4/original_website3/sites/all/modules/data/data_search/data_search.module).
Warning: Invalid argument supplied for foreach() in data_search_get_fields() (line 189 of /home/kbailey/projects/icmsv4/original_website3/sites/all/modules/data/data_search/data_search.module).

and the tables were then adopted.

Funny thing is - one table has a view created ok - but the other one doesn't.

BTW - I have not enabled the node and taxonomy parts of the data modules.

OK - the views can get created - but it seems a bit weird.

Create a new table outside of the module - i.e. using phpmyadmin - adopt it - no view is available.

Now, create another table outside of the module - adopt it - then the view for the previously adopted table is now available.

I think this is what we used to call end error - some array somewhere is expecting a 0 and is being fed a 1 - or vice-versa

@#6 - bailey86... thats not working for me. I created 3 tables table adopted one, then the other... nothing.

But... I did figure this out I think. Your have to have a primary key. If the nothing is set as primary... no view.

> If the nothing is set as primary... no view.

Yup, that's expected behaviour. Views requires tables to have a primary key.

Could someone try to reproduce this with a table that has a PK?

I can confirm that a PK is needed - the tables I created all had PK's - but the adopted table would only show after I'd adopted another table.

Could this be related to caching?

IIRC the code around creation of PKs is a bit convoluted. Might well be in there somewhere.

I think that a notification message after adopting a table that says "This table does not have a primary key so views integration will not work with this table" would help users out a lot.

Mine had a primary key, and yet view creation would fail - until I created another table and adopted it as suggested by #6 above. Weird solution, but it worked.

Re comment 6 -- could someone try and debug this to see where the problem is?

Hey Joachim, I'm knee deep in the 2nd database code, but since I'll be looking into views soon, I'll check on this.

looking to the code in data_ui_views_default_views which is silently skipping a table without a primary key is a major issue. Especially for external tables this acutally might be the case. E.g. "database views" might be pretty common, as such the underlaying might in deed might have a pri-key, but this is not "see-able" within Drupal.
The editor under "/admin/structure/data/edit/TYPE" will try to write down to the DB, which will produce a PDO error in case you try to create a pri-key index for a view.

The weired solution of adopting another table worked for me too,

I found that a cache clear all after adopting a single table causes the view to appear. The data_search errors arise because the adopted table is not fully available when data_search_views_data_alter() runs until the cache clear.

This may not help you guys (existing replies) one iota but it may help others coming in afresh. I was getting this "Warning: array_keys() expects parameter 1 to be array," myself after upgrading my local dev machine from XAMPP 1.7.1 (php circa 5.2.9, and yes I can't believe it was that old either!) to XAMPP 1.8.2 (PHP 5.4.16) and BOOM the site was covered in "Warning: array_keys() expects parameter 1 to be array," warnings (hence coming here). In my case the problem was as simple as my host headers weren't updated and so htpp://localhost/site-xxx was generating the warnings but as soon as I added the correct header info back (i.e. the httpd-vhosts.conf and the windows system 32 hosts files) to http://site-xxx respectively, the warnings disappeared.

I sincerely hope that helps anyone else that has the same problem. And if it helps any of you (above) guys too then all the better. ;-)

Q.

Several people in this thread mentioned these warnings when adopting tables:

Warning: array_keys() expects parameter 1 to be array, null given in data_search_get_fields() (line 187
Warning: Invalid argument supplied for foreach() in data_search_get_fields() (line 187 of

However, I did not find this as a bug report. Should we file that separately?

Yup, good idea.

Posted at https://www.drupal.org/node/2524344 as separate bug report.

This looks alike a serious meta-issue, I see 3:

1. Adopting table throws array_keys warning.. https://www.drupal.org/node/2524344
2. Adopting a Table without a Primary Key does not create a view (either "Closed, works as intended" or do a small warning message patch per #11)
3. Adopting a Table requires Cache Clear to show in Views - should be created as a separate issue

I will work on #2 and #3 if @joachim thinks it the way to go.

Joachim is very much an absentee maintainer at this point -- a combination of no longer using this module in any of my projects at work, and not much spare time. I try to check on this issue queue from time to time, and I commit patches that either are simple enough to eyeball review, or have been reviewed by other users.

For #2 though, I would say show the message before the user adopts the table. I don't recall the UI, but assuming it's a set of checkboxes for table names, you can add a description to a checkbox by setting $form[CHECKBOXES ELEMENT][VALUE][#description] (after you build the checkboxes element of course). Adding it there would make sense to me.

> Joachim is very much an absentee maintainer at this point
Well he's the best we've got at the moment :) -- I will proceed on all of the above.

The attached patch sets asterisks(*) by tables that lack a PK with a descriptive message at the bottom. Also the "Edit" screen for any already adopted table gives a prefix and suffix message if the table lacks a PK, letting the users know that they shouldn't expect to see the table exposed to Views. Changing to needs review.

Looks good, but a few tweaks needed:

1. +++ b/data_ui/data_ui.admin.inc
   @@ -256,9 +256,12 @@ function data_ui_adopt_form($form, $form_state) {
   +  $form['#suffix'] = '* Tables without a primary key will not be exposed to Drupal Views.  The Data module can create a primary key on tables after adopting via the \'Edit\' function.';
   

   Since this needs a reroll anyway, prefer " for strings that have apostrophes. Easier to read, better DX, and makes life nicer for translators too... and you've forgotten to wrap this in t()... Leave the '*' out of the t() though, as that may confuse translators out of context.

2. +++ b/data_ui/data_ui.admin.inc
   @@ -531,11 +534,14 @@ function data_ui_edit_form($form, &$form_state, $table) {
   +  $has_pk = false;
   

   Constants should be in capitals: FALSE.

3. +++ b/data_ui/data_ui.admin.inc
   @@ -531,11 +534,14 @@ function data_ui_edit_form($form, &$form_state, $table) {
   +        $has_pk = isset($schema['primary key']) ? in_array($field_name, $schema['primary key']) : $has_pk;
   

   Not sure ternary is the right thing here.

   if (isset}
   pk = in array());
   }

   would be easier to read.

4. +++ b/data_ui/data_ui.admin.inc
   @@ -578,7 +584,10 @@ function data_ui_edit_form($form, &$form_state, $table) {
   +    $form['#prefix'] .= '<div>This table does not have a primary key defined.  Tables without primary keys will not be exposed to Views.</div>';
   +    $form['#suffix'] .= '<div>This table does not have a primary key defined.  Tables without primary keys will not be exposed to Views.</div>';
   

   Do we need this at both top & bottom?

@joachim - thanks for the guidance - it all makes sense to me. Per #4, I included it at top and bottom in anticipation of really long tables, to make sure that it was visible to the user - especially in mobile. But that may be over-thinking it a mite, easy enough to add a second notation back if it proves necessary. I put it at the top of the table in newest version.

I have also updated the Data Documentation to include information about adopting tables and the PK requirement for Views integration.

https://www.drupal.org/node/2565009

The method to adopt another table indeed 'liberated'the view, but I am still miles away from a search engine for my table.

Updating title to avoid confusion with #2565249: Adopting a Table requires Cache Clear to show in Views.