We need to support simple filters, pagination and sorting from user-core APIs. I don't think there is a defined list of complex filters; it is endless. So we can't support it from user-core. So what we can do is we can provide a default implementation to evaluate complex filters using simple filters in SCIMUserManager, and if someone wants to extend it they need to extend SCIMUserManager implementation.
On Fri, Nov 4, 2016 at 1:15 PM, Darshana Gunawardana <[email protected]> wrote: > Hi, > > Do we have the support for complex filters, pagination, sorting from the > C5 user-core? > > If not, we should support these since these are some major limitations we > had in C4 user-core and we should avoid those limitations in C5. > > Thanks, > > On Thu, Oct 20, 2016 at 9:41 AM, Vindula Jayawardana <[email protected]> > wrote: > >> Hi Chamila, >> >> On Tue, Oct 18, 2016 at 4:18 PM, Chamila Wijayarathna < >> [email protected]> wrote: >> >>> Hi Johann, Vindula, >>> >>> On Tue, Oct 18, 2016 at 3:59 PM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Oct 18, 2016 at 10:05 AM, Vindula Jayawardana <[email protected] >>>> > wrote: >>>> >>>>> Hi All, >>>>> >>>>> With the current user core implementation we support only the equal >>>>> filter (e.g. userName Eq "john"). However SCIM 2.0 specification [1] >>>>> specify total of 10 such simple filters and complex filters which are >>>>> combinations of simple filters using logical and grouping operators (e.g. >>>>> userType ne "Employee" and not (emails co "example.com" or >>>>> emails.value co "example.org")). As we are in the process of C5 >>>>> implementation, have we considered the other filter type implementations >>>>> as >>>>> well? >>>>> >>>> >>>> Yes we need to consider these features in the extended user-core >>>> implementation. >>>> >>>>> >>>>> Moreover if we are supporting the complex filters, are we supporting >>>>> it by simple filter by filter basis or the entire complex filter as a >>>>> whole? If we are looking for the simple filter by filter basis, there will >>>>> be performance issues as well. >>>>> >>>> >>>> It is better if we provide complex filters from extended user-core >>>> itself for performance reasons. However if time doesn't permit to implement >>>> all those APIs, we can have a scim UserManager implementation which will >>>> call multiple simple filters and combine the result and return. Obviously >>>> as you said performance of such implementation will be low. But it is >>>> acceptable as an interim solution until extended user-core implementation >>>> supports all the filters. >>>> >>> Can you please explain, what you refer as complex filters here? I think >>> we need to implement operators listed in table 3 and 4 in the specification >>> and implement a generic way to build complex queries reusing them. I don't >>> think it would be practical to more complex filters, there can be large >>> amount of complex filters that can be created by combining these simple >>> filter. Please correct me if I'm wrong. >>> >> >> What I meant by complex filters is exactly what you have mentioned above. >> Yes we can build large amount of complex filters (complex queries) by >> combining the simple filters using operators listed in table 3 and 4. >> >>> >>> Also what different would it made when we are handling these filters in >>> user-core level and when handling using scimUserManager level? Are you >>> reffering to the fact that when we need "username sw a" , we can retrieve >>> only the users who have username start with 'a' from database/ldap, so >>> that we can achieve higher performance? >>> >>> In addition to that, I believe it would be good to consider other SCIM >>> operations such as sorting and pagination at the same time. If we can come >>> up with a generic design, that would be better. Otherwise, we'll have to >>> put a huge effort to embed those functionalities again. >>> >> >> Yes agree. We need a generic design which will ease our work in the long >> run. >> >>> >>> Cheers >>> -Chamila >>> >>>> >>>>> Any thoughts on the matter is highly appreciated. >>>>> >>>>> [1] https://tools.ietf.org/html/rfc7644#section-3.4.2.2 >>>>> >>>>> Thank you, >>>>> >>>>> *Vindula Jayawardana* >>>>> Trainee Software Engineer >>>>> Mobile : +94 713 462554 >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Technical Lead & Product Lead of WSO2 Identity Server >>>> Governance Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Chamila Dilshan Wijayarathna, >>> PhD Research Student >>> The University of New South Wales (UNSW Canberra) >>> Australian Centre of Cyber Security >>> Australian Defence Force Academy >>> PO Box 7916, Canberra BA ACT 2610 >>> Australia >>> Mobile:(+61)416895795 >>> >>> >> >> >> -- >> *Vindula Jayawardana* >> Trainee Software Engineer >> Mobile : +94 713 462554 >> Email : [email protected] >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Regards, > > > *Darshana Gunawardana*Associate Technical Lead > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
