[ https://issues.apache.org/jira/browse/SLING-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770902#action_12770902 ]
Alexander Klimetschek edited comment on SLING-1131 at 10/28/09 11:54 AM: ------------------------------------------------------------------------- > the key went away Because the key is not mandatory (for quite a while), because if it is not present, the node name is used (that's why I added [...@sling:message] to fetch only all nodes that have at least that required property set). In my (manual) tests it worked fine, albeit as you note it now, I wonder why the /@sling:message was necessary to get the property, but a missing /@sling:key does work somehow. I think we could change the code to use a NodeIterator for the results (or Resource iterator when the resource query api is used) and not use the IMHO somewhat awkward row iterator JCR result. I will try to write a test case and verify it, albeit that involves the repository and thus needs a bit more effort. was (Author: alexander.klimetschek): > the key went away Because the key is not mandatory (for quite a while), because if it is not present, the node name is not used (that's why I added [...@sling:message] only to fetch only all nodes that have at least that required property set). In my (manual) tests it worked fine, albeit as you note it now, I wonder why the /@sling:message was necessary to get the property, but a missing /@sling:key does not work. I think we should change the code to use a NodeIterator for the results (or Resource iterator when the resource query api is used) and not use the IMHO somewhat awkward row iterator JCR result. I will try to write a test case and verify it, albeit that involves the repository and thus needs a bit more effort. > i18n: do not enforce a flat node hierarchy below mix:language > ------------------------------------------------------------- > > Key: SLING-1131 > URL: https://issues.apache.org/jira/browse/SLING-1131 > Project: Sling > Issue Type: Improvement > Components: Extensions > Affects Versions: I18n 2.0.2 > Reporter: Alexander Klimetschek > Priority: Minor > Fix For: I18n 2.0.2 > > Attachments: SLING-1131.patch > > > Currently the search for translations enforces a flat hierarchy below the > mix:language node (that eg. says 'de' for the translation language) for the > sling:Message nodes that hold the single translations. If you have many > translations, eg. thousands, the flat hierarchy can get slow in Jackrabbit, > so it would be good to support a nested hierarchy as well. > The change boils down to the query that is done. Currently it looks like this > (eg. for fetching all translations for 'de'): > //element(*,mix:language)[...@jcr:language='de']/*/(@sling:key|@sling:message) > It should introduce a descendant-or-self step: > //element(*,mix:language)[...@jcr:language='de']//*/(@sling:key|@sling:message) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.