Adopt table from any module

subscribe

subscribe

Note that commenting the line mentioned by the OP allows you adopt any database (regardless of schema), however, it WILL delete the table if you drop the table from data.

I think that it is good that the UI only allows adoption of orphaned tables. It prevents the headaches of accounting for present views handling of the tables that are already in place, and avoids the display of potentially sensitive data to 'Joe Site-admin'.

That being said it's relatively easy to programmatically adopt any table in the database if you need to.

<?php
data_include('DataTable');
$my_table_object = DataTable::instance('my_table');
$my_table_object->adopt();
DataTable::clearCaches();
?>

Where my_table is the table name you intend to adopt.

I think it is pretty useful to adopt tables that are declared by other modules. Many modules don't have views support and it would be a waste of time to write that if this module does it out of the box. In Drupal "Joe Site Admin" has a lot of power to destroy what they like. Attached is a patch that warns the user about adopting tables that already have views declared and changes the name from "Orphaned" to "Adoptable".

I updated the patch so that a user can adopt any table that is not already adopted and does not already have a views definition. This way you can automatically create views definitions for modules that don't declare them.

This missing link for many use cases is that many modules provide views integration without providing a base table so a user can't make a view of them.

> Here we could have for example tables from modules that have not implemented Views integration and implement it for them easily, relate them to node etc..

Is that the only benefit of this proposed feature? Because if so, the correct fix is to implement Views integration for the module in question!

How long does it take to make views integration with a given module? Why not just let someone do that with this module? Isn't the whole point to manage tables through the UI.

The point of this module is to manage *foreign* tables in the UI, which contain raw data that is not used by any module.

If you start mucking around with tables that modules are counting on, you're going to have a big mess on your hands.

Is there another module you are familiar with that allows you to create views definitions for tables that don't have them already? I know that Table Wizard used to do that. I agree that managed tables shouldn't be changed but integrating them with Views and being able to add relationships to views seems useful. Would it be better to only allow you to make a views integration with managed modules or have a separate module that does so?

Views support for a module should be in that module's code.

> you can't ask for the developper to do it asap.

You can always provide a patch :)

> And it takes time to do so while this module could do it in one click.

But then when Views support *does* come to that module, all your views will need to be re-made. Because Data module can only add a rough, general one-size-fits-all Views support. Tables and fields will be given generic names, which custom-made support will quite likely change.

@joachim I see the wisdom in what you are saying. Creating custom views definitions can be time consuming, so maybe a happy medium would be for an easy way to get off the ground with that by providing a code export for creating that. Probably outside of the scope of this project.

While the "right" way to handle making a Drupal module's table available to Views is to add that functionality to a module, doing so is significantly more difficult for a non-coder than using Data would be.

It's true that doing it through the module would make the functionality available to all module users, but it also depends on the bandwidth of the module maintainer to integrate what would probably be a patch and many patches are languishing in Drupal 7 and some are already obsolete, as the modules get upgraded before integrating existing patches. I'm concerned that this will only get worse for Drupal 7 modules as we get closer to Drupal 8.

Could there be some tweaks and best practices that would minimize the potential problems when using Data with existing modules that don't have views integration?

For example, if an upgrade to a module supports views, could a message be generated in the status report warning of a potential conflict? As a best practice, are there naming conventions that could be used in Data that would avoid potential conflicts if the module adds views support at a later date? In the worst case of unavoidable conflicts, forewarned developers might be willing to accept the trade-off of recreating views vs learning how to provide views integration to a module.

Any chance of rethinking this? Thanks.