@Mark Reynolds@Mark Reynolds
>>> The code itself looks fine to me, but I find it odd you are testing matching rules by creating COS entries in two of those PRs.
Cos entries are used here as part of (
objectclass: extensibleObject
)
As cos template has (
objectclass: ['top','cosTemplate' , 'extensibleObject']
)
Which is the nearest one of row extensibleObject entry.
Ah okay I see. Please add a comment that you are really just
trying to use an entry with extensibleObject, because it is
currently confusing.
>>> I don't think that is actually doing anything in regards to matching rules. I was under the impression that matching rules are only applied/enforced during searches (not Adds or Modifies). So you are checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that has to do with matching rules. Or, maybe I am just missing what this test is trying to do as I am not that familiar with MRs. So if you can clarify that for me I would appreciate it
Please refer bellow ldif file and TET Filter suit which is part of Filter test suit . To See whats going on Please see the original TET Filter suit . ( test series mr_*() )
Filter TET Script : http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filter/filter.sh
LDIF FIle: http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
LDIF FIle: http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/booleanMatch.add.ldif
Thanks for providing more background on this. The rest looks good to me.
Thanks,
Mark
Regards
Anuj Borah
On Wed, Jul 17, 2019 at 5:38 AM Anuj Borah <aborah@redhat.com> wrote:
@Mark Reynolds>>> The code itself looks fine to me, but I find it odd you are testing matching rules by creating COS entries in two of those PRs.
Cos entries are used here as part of ()objectclass: extensibleObject
As cos template has (objectclass:['top','cosTemplate' , 'extensibleObject'])
Which is the nearest one of rowextensibleObject entry.
>>> I don't think that is actually doing anything in regards to matching rules. I was under the impression that matching rules are only applied/enforced during searches (not Adds or Modifies). So you are checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that has to do with matching rules. Or, maybe I am just missing what this test is trying to do as I am not that familiar with MRs. So if you can clarify that for me I would appreciate it
Please refer bellow ldif file and TET Filter suit which is part of Filter test suit .To See whats going on Please see the original TET Filter suit . ( test series mr_*() )
Filter TET Script : http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/testcases/DS/6.0/filterLDIF FIle: http://git.app.eng.bos.redhat.com/git/dirsrv-tests.git/tree/data/DS/6.0/filter/en/mrsearchtests.ldif
Regards
Anuj Borah
On Wed, Jul 17, 2019 at 2:21 AM Mark Reynolds <mreynolds@redhat.com> wrote:
On 7/15/19 8:00 AM, Anuj Borah wrote:
The code itself looks fine to me, but I find it odd you are testing matching rules by creating COS entries in two of those PRs. I don't think that is actually doing anything in regards to matching rules. I was under the impression that matching rules are only applied/enforced during searches (not Adds or Modifies). So you are checking for TYPE_OR_VALUE_EXISTS errors in some of the tests, and I don't see what that has to do with matching rules. Or, maybe I am just missing what this test is trying to do as I am not that familiar with MRs. So if you can clarify that for me I would appreciate it
Thanks,
Mark
Regards
AB
A
On Tue, May 21, 2019 at 4:17 PM Anuj Borah <aborah@redhat.com> wrote:
On Wed, May 15, 2019 at 8:50 PM Anuj Borah <aborah@redhat.com> wrote:
On Thu, May 9, 2019 at 5:27 PM Anuj Borah <aborah@redhat.com> wrote:
On Tue, Apr 30, 2019 at 4:03 PM Anuj Borah <aborah@redhat.com> wrote:
Hi Simon ,
Rebsed onto master .
RegardsAnuj Borah
On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin <spichugi@redhat.com> wrote:
On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote:
> Hi all,
Hi Anuj,
> Please review these PRs.
> Pending from Long Time.
> [1]https://pagure.io/389-ds-base/pull-request/50180
> [2]https://pagure.io/389-ds-base/pull-request/50192
Could you please rebase them onto master?
Thanks,
Simon
> Regards
> Anuj Borah
>
> References
>
> 1. https://pagure.io/389-ds-base/pull-request/50180
> 2. https://pagure.io/389-ds-base/pull-request/50192
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org-- 389 Directory Server Development Team
-- 389 Directory Server Development Team