It would be really awesome if CTools' export system allowed for:

  • Automatic detection of the primary key from the schema record.
  • Compound primary keys, e.g. the {emf_roles} table from the emf module.
CommentFileSizeAuthor
#14 924236_ctools_multi_key.patch503 byteshefox
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

Title: Better Primary Key auto-detection, support for compound primary keys » Primary key auto-detection, support for compound primary keys
DamienMcKenna’s picture

Small correction, it's the {emf_list_roles} table.

DamienMcKenna’s picture

My initial thought on this was to:

  • Implode the key values with a static divider.
  • Adjust the exporting & importing to handle the keys accordingly.

I've done some initial work on the EMF ticket and have exporting working, I just need to complete the loading/importing, see what other callbacks should be added and then generalize it rather than it being hardcoded for the EMF tables.

DamienMcKenna’s picture

DamienMcKenna’s picture

Another module this would help with: NodeRelationships

DamienMcKenna’s picture

Version: 6.x-1.7 » 6.x-1.8
DamienMcKenna’s picture

Reviewing the code it seems that support for single-value keys is pretty hardcoded into the export functionality, e.g.:
export.inc line 357:

    if (!isset($export['key in table'])) {
      $conditions[] = "$export[key] IN (" . db_placeholders($args, $schema['fields'][$export['key']]['type']) . ")";
    }
    else {
      $conditions[] = "$export[key] IN (" . db_placeholders($args, $join_schemas[$export['key in table']]['fields'][$export['key']]['type']) . ")";
    }

Clearly this would need work to support multiple keys.

DamienMcKenna’s picture

Have been doing some thinking on this. One of the key issues is the need to still have a single, unique identifier for a given record, despite the compound primary keys. It would have to be something that is bi-directional, so that it could be passed through forms and the acting functions could then be able to act on the data transmitted. Rather than trying to decide on an arbitrary divider string for implode/explode, I think serializing the array of key values will be simpler.

DamienMcKenna’s picture

I used some of my ideas to make NodeRelationships exportable: http://drupal.org/node/660958#comment-4119418

DamienMcKenna’s picture

Maybe there should be an option on whether to serialize the data? In most cases the keys are very simple alphanumeric strings and having the unique identifier as just a concatenated string of the keys would make debugging easier too.

merlinofchaos’s picture

I do agree that serialization seems extreme and in most cases is probably not wanted.

Dave Reid’s picture

Issue tags: +Metatags, +pathauto, +xmlsitemap

This is likely going to block anything exportable for Meta tag, Pathauto, or XML sitemap configuration in D7 as I want to store config with a compound primary key based on entity/bundle storage. (tagging with other contrib modules that are affected)

DamienMcKenna’s picture

@DaveReid: take a look at what I was working on for NodeRelationships, it's definitely not complete but appears to have some of the basics working the way I intended.

hefox’s picture

FileSize
503 bytes

Here's a tiny winy start of a patch that is so far from being complete I don't want to mark this needs *

The idea here is to calculated key based on a 'keys' area in 'export' array of schema. Well, actually, the idea was to get #660958: ctools export intergration (features support) working with ctools load objects. 'names' doesn't work (where the snippit from above is I believe), etc.

JacobSingh’s picture

Subscribe

Dave Reid’s picture

Issue tags: -Metatags

No longer blocking Metatags. Decided to go with a simple machine name as 'entity-type:bundle' joined with a colon for now.