On 18.12.2013, at 21:44, Tobias Bocanegra <tri...@apache.org> wrote: > I don't really like the automatic upgrade, since we really don't know > how to differentiate use of mix:language/sling:message in compact > subtrees vs the sparse case. It might be to expensive to traverse the > mix:language nodes for each bundle activation.
We don't need a traversal - just that one query we currently already do and which we want to replace because it is potentially a bit slow. And it's only on the _first_ bundle activation, afterwards the "has been migrated" flag is set. The nested mix:language scenario should be easy to handle by just looking at the paths: + mix:language ... + mix:language ... + sling:Message If you get nested paths, you only look at the longer one. The only awful scenario could be this: + mix:language ... + sling:Message .... + mix:language ... + sling:Message But it doesn't make any sense, so I can't imagine anyone using it. > I would rather have a semi automatic fallback as described before: > > 0. read the operation-mode osgi config property (default: auto). > 1. if mode==auto: > 1.1 search (query) for all sling:Dictionary nodes > 1.2. if non found, assume old content and set mode=legacy That only allows one version at the same time. If we update the ootb dictionaries in our application to use the sling:dictionary node types, but customers have their own dictionaries, these would not work anymore after upgrading. Cheers, Alex