From @alexpott in #1735118-113: Convert Field API to CMI :


+ * Note: the class take no special care about importing instances after their
+ * field in importCreate(), since this is guaranteed by the alphabetical order
+ * (field.field.* entries are processed before field.instance.* entries).

This comment proves we need to refactor the config import process so we can implement a way for config providers to say that this config needs to be imported before this other piece of config. Relying on the alphabet is smelly :)


swentel’s picture

Issue tags: +Configuration system

Better tag (I think)

heyrocker’s picture

When we originally had this discussion like a year and a half ago we talked about using the module dependencies graph as an ordering mechanism. This seems like the simplest solution to make happen?

xjm’s picture

Category: task » bug
Issue tags: -CMI

I'd call this a bug. I'm tempted to cal it a major bug. That seems pretty fragile. :)

Re: using module dependencies, I don't think that solves the problem. A module should be able to declare an arbitrary import order for its own config data depending on its internal needs. Like the field/field instance example.

beejeebus’s picture

i suspect we'll end up wanting something like what we implemented after discussions at badcamp aaaaaages ago?

that is, allowing multiple cycles over the import list, and a mechanism for modules to say 'hey, call me again'.

or something else, if the current import code can't be made to work that way any more.

xjm’s picture

xjm’s picture

Priority: Normal » Major
xjm’s picture

xjm’s picture

Status: Active » Closed (duplicate)
xjm’s picture

Issue summary: View changes

Better link