I would like to get back to your use case, you mention this is search right?
Even with such a method, doing the search is tricky as we have this strange setup of a resource optionally returning a resource super type. For example: If a resource returns A as the resource type and null as the resource super type, this resource is of type A and all parent types of A. However, if a resource returns A as the resource type and B as the resource super type, this resource is of type A, B and all parent types of B - but not the parent types of A. If search is the use case, I believe that we should finally at something like the search api I proposed a long time ago and then we could add a predicate for this and code all the logic once in a general implementation. Regards Carsten Konrad Windszus wrote > After thinking a bit more about it I would propose the following > a) Extend the ResourceResolver interface like outlined in > https://github.com/apache/sling-org-apache-sling-api/pull/2 > <https://github.com/apache/sling-org-apache-sling-api/pull/2> > b) In ResourceResolverImpl reference a ResourceTypeInheritance service > singleton which caches resource super types of all resources below /apps and > /libs > - this cache should be populated via resource traversal (that should be > supported by all resource providers) > - the cache should be invalidated via the ResourceChangeListener > > That way the cache is an implementation detail and I would also explicitly > mention in its javadoc that this is not supposed to be consumed except from > within the Resource Resolver. The cache can even be located in the Resource > Resolver bundle and its interface does not even need to be exported. > > WDYT? > > >> On 12. Jan 2018, at 15:46, Konrad Windszus <[email protected]> wrote: >> >>> >>> >>> Resource resolver is short lived, so caching there doesn't provide that >>> much value. You need something "global". >> I see, so the cache must be bound to something else. The only thing which >> comes to mind is the ResourceResolverFactory, but I would like to keep that >> new method and the method getResourceSuperType in the same interface >> (because one is just the inversion of the other). Any other idea except for >> a completely new OSGi service? >> >>> >>> Most clients of resource resolver do not care about resource types at >>> all, so adding more stuff to that interface doesn't make it nicer for >>> most use cases of resource resolver. >>> >>> A solution which is only limited to JCR is imho not a good idea and >>> putting the burden on resource providers is as you point out too much >>> effort and not necessary. Resource type inheritance is a cross cutting >>> concern. >> I cannot think any other solution than those two. >> >>> >>> Regards >>> >>> Carsten >>> >>> >>> Konrad Windszus wrote >>>> Why do you want to separate it from the ResourceResolver interface? >From >>>> a consumer perspective this sound like the perfect fit. In the >>>> ResourceResolveImpl we can then implement such a cache (but this would be >>>> an implementation detail and not part of the API). >>>> >>>> I am thinking about a best effort approach like querying recursively with >>>> SQL2. Of course this would only return results for the JCR Resource >>>> Provider (but I think that is sufficient for 99% of the cases). >>>> >>>> Another approach would be to require every Resource Provider to provide >>>> that information and I think this is too much of an effort for right now. >>>> Later on we can easily extend/improve the implementation by extending the >>>> Resource Provider interface. >>>> WDYT? >>>> >>>>> On 12. Jan 2018, at 15:25, Carsten Ziegeler <[email protected]> wrote: >>>>> >>>>> I think some time ago we discussed a separate resource type mgmt service >>>>> (which also could cache resource type resolution). >>>>> >>>>> Maybe now is a good time to think about it and introduce it? >>>>> >>>>> Regards >>>>> >>>>> Carsten >>>>> >>>>> >>>>> Konrad Windszus wrote >>>>>> Yes, exactly. >>>>>> But if someone has a better idea on how to achieve that I am eager all >>>>>> ears. >>>>>> >>>>>>> On 12. Jan 2018, at 15:19, Jason Bailey <[email protected]> wrote: >>>>>>> >>>>>>> So that I understand, this would benefit a scenario where you are >>>>>>> searching for a specific resource type, and the search implementation >>>>>>> would have to traverse up the resourceType hierarchy to determine if a >>>>>>> specific type was of a type that you are looking for. >>>>>>> >>>>>>> One of the solutions for this, as you suggest, could be a pre-emptive >>>>>>> determination of the derived types and then the search implementation >>>>>>> could compare against that. >>>>>>> >>>>>>> Did I get that right? >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Konrad Windszus [mailto:[email protected]] >>>>>>> Sent: Friday, January 12, 2018 5:46 AM >>>>>>> To: [email protected] >>>>>>> Subject: Re: Search for specific resource types >>>>>>> >>>>>>> EXTERNAL >>>>>>> >>>>>>> Ping, does anyone have any idea? >>>>>>> >>>>>>> I am thinking about introducing a new method to ResourceResolver which >>>>>>> allows to return all derived resource types for a given resource type. >>>>>>> That must internally rely on a search within /apps and /libs looking >>>>>>> for resourceSuperType=<given type> recursively! >>>>>>> >>>>>>> Such a method could be used as a basis for the query to look for >>>>>>> content of type "a" or a derived type. >>>>>>> WDYT? >>>>>>> >>>>>>> Konrad >>>>>>> >>>>>>>> On 15. Dec 2017, at 16:59, Konrad Windszus <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> is there a simple way to search with Sling Resource API for resources >>>>>>>> which have a certain resource type "a" or a resource type derived from >>>>>>>> "a". >>>>>>>> The resource type inheritance in Sling is a pretty powerful concept. I >>>>>>>> am wondering how to properly support that when searching for content >>>>>>>> which is either of resource type a directly or a derived resource type. >>>>>>>> >>>>>>>> I cannot really think of a JCR SQL2 or XPath expression which would >>>>>>>> also cover derived resource types (without knowing them in advance). >>>>>>>> Thanks for any pointers, >>>>>>>> Konrad >>>>>>> >>>>>> >>>>> -- >>>>> Carsten Ziegeler >>>>> Adobe Research Switzerland >>>>> [email protected] >>>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >> > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
