After making changes to terms/vocabularies and exporting them to configuration, we're seeing lots of these:

-      tid: '1'
+      tid: '16'

...and...

-      parent: '332'
+      parent: '328'

...which fill up our code reviews and don't actually serve any useful purpose because we're relying on UUIDs, not tids. (See #3032480: Entity IDs inconsistent across exports and imports for more info on that.)

To make git diffs and commits (e.g. git add -p) easier to handle, these changes should be ignored before we even get to that stage. To do that, Structure Sync shouldn't be generating these changes at all.

While I'm a maintainer, I'd like to ensure major use cases are supported. For example,

  • Would this cause problems for anyone?
  • Is everyone running into the same problem?

Please add your thoughts, patches, etc.

Comments

colan created an issue. See original summary.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented
Issue summary: View changes
heikkiy’s picture

heikkiy commented

At least our workflow does rely sometimes on term ID's mainly because they are easier to use as contextual filters in Views. We do also use UUID's sometimes but the fact is that for example for Views, the support is better for term ID's as contextual filters so this would break our current workflow.

Could this be an option in the module?

eahonet’s picture

eahonet commented

We also find Views, Search_api, and other modules do use TIDs. That's was a driving factor to using Structure Sync. Removing TIDs from Structure Sync would make the module less useful.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented

I was using it with all the core/views patches that switch everything to UUIDs, but having this be an option makes sense (at least until all of the other code gets in).

guypaddock’s picture

guypaddock commented

Note that this appears to clash with the intent of #3032480: Entity IDs inconsistent across exports and imports.