On 18.12.2013, at 21:44, Tobias Bocanegra <[email protected]> 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
