Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#14 | 924236_ctools_multi_key.patch | 503 bytes | hefox |
Comments
Comment #1
DamienMcKennaComment #2
DamienMcKennaSmall correction, it's the {emf_list_roles} table.
Comment #3
DamienMcKennaMy initial thought on this was to:
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.
Comment #4
DamienMcKennaA link to the EMF work: #924194: Features / CTools Export support
Comment #5
DamienMcKennaAnother module this would help with: NodeRelationships
Comment #6
DamienMcKennaComment #7
DamienMcKennaReviewing the code it seems that support for single-value keys is pretty hardcoded into the export functionality, e.g.:
export.inc line 357:
Clearly this would need work to support multiple keys.
Comment #8
DamienMcKennaHave 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.
Comment #9
DamienMcKennaI used some of my ideas to make NodeRelationships exportable: http://drupal.org/node/660958#comment-4119418
Comment #10
DamienMcKennaMaybe 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.
Comment #11
merlinofchaos CreditAttribution: merlinofchaos commentedI do agree that serialization seems extreme and in most cases is probably not wanted.
Comment #12
Dave ReidThis 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)
Comment #13
DamienMcKenna@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.
Comment #14
hefox CreditAttribution: hefox commentedHere'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.
Comment #15
JacobSingh CreditAttribution: JacobSingh commentedSubscribe
Comment #16
Dave ReidNo longer blocking Metatags. Decided to go with a simple machine name as 'entity-type:bundle' joined with a colon for now.