[389-devel] Re: Trying to understand entryrdn.db
Let's discuss more on it. > > On Aug 3, 2017 at 07:33, mailto:lkris...@redhat.com)> > wrote: > > > > > On 08/03/2017 12:24 PM, Ilias Stamatis wrote: > > > > > > > > > > That said, whenever you write an entry you always have seen the parent > > > and could stack the dn with the parentid and createt the dn without using > > > the entryrdn index. > > > You even need not to keep track of all the entry rdsn/dns - only the > > > ones with children will be needed later, the presence of "numsubordinates" > > > identifies a parent. > > > > > > > > Interesting. I think I now understand better how to approach this problem. > >great. just one more hint. If you iterate the the entries in > > id2entry you have the entryid and the parentid of the entry. if parentid > > > entryid you need to get and export the parent first (an track that you did > > it already) > > > > > > > > > I'll get back to it soon. > > > > Thanks so much! > > > > > > > Last but not least, since I think dbscan is broken for entryrdn, > > investigating and fixing this would also be nice > > > > Sure. I'll open a ticket so it gets tracked. > > > > > > ___ 389-devel mailing list -- > > 389-devel@lists.fedoraproject.org > > (mailto:389-devel@lists.fedoraproject.org) To unsubscribe send an email to > > 389-devel-le...@lists.fedoraproject.org > > (mailto:389-devel-le...@lists.fedoraproject.org) > > > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: > Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > ___ 389-devel mailing list -- > 389-devel@lists.fedoraproject.org To unsubscribe send an email to > 389-devel-le...@lists.fedoraproject.org > ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Trying to understand entryrdn.db
> > That said, whenever you write an entry you always have seen the parent and > could stack the dn with the parentid and createt the dn without using the > entryrdn index. > You even need not to keep track of all the entry rdsn/dns - only the ones > with children will be needed later, the presence of "numsubordinates" > identifies a parent. > Interesting. I think I now understand better how to approach this problem. I'll get back to it soon. Thanks so much! > Last but not least, since I think dbscan is broken for entryrdn, investigating and fixing this would also be nice Sure. I'll open a ticket so it gets tracked. ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Please review: Draft of the big lib389 and pytest guide
Hi team, a new version: https://pagure.io/lib389/issue/77#comment-451622 https://pagure.io/lib389/issue/raw/files/6047ac156e06192837271afc2770a83f7f3206400669537bb1d8f43ab7b9a434-Guidelines-for-using-pytest-and-lib389_47541162.html Thanks, Simon On Wed, Jul 19, 2017 at 04:31:50PM +0200, Simon Pichugin wrote: > Hi team, > > https://pagure.io/lib389/issue/77#comment-449299 > https://pagure.io/lib389/issue/raw/2aef109dbf0f23a359c15f209c6c523cebda4faf583125ff62e0a228f8c3b321-Guidelines-for-using-pytest-and-lib389_47541162.html > > Thanks, > Simon > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org signature.asc Description: PGP signature ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review 49337: CI test - import
https://pagure.io/389-ds-base/issue/49337 https://pagure.io/389-ds-base/issue/raw/files/24b19f4e3af39329fa9c53a67a9cb096e6a8bd536561b261bedb77d642cae179-0001-CI-test-import-bugzilla-test-cases.patch ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Trying to understand entryrdn.db
On 08/02/2017 09:12 PM, Mark Reynolds wrote: On 08/02/2017 02:19 PM, Ilias Stamatis wrote: I see now, thank you both very much! Follow-up: [1] Get entry from id2entry and use its ID [2] Look in entryrdn for the parent of the ID [3] Keep looking for parents, building the DN as you go along Example: [1] Get entry from id2entry: ID 6 --> "cn=Accounting Managers" [2] Check entryrdn for "P". In this case it's "P6" which is "ou=Groups" with ID 3 [3] So find "P3", which is "dc=example,dc=com" with ID 1, and look for "P1". But there is no P1, so we stop the process/loop. Why do we need to look at entryrdn for parent's id? Is it faster? I have not looked closely into it - so it might not be necessary to use entryrdn. I thought it might be more efficient to use it. If you just use id2entry, you have to keep scanning it over and over, and starting over every time you need to read the next entry. Maybe not though, maybe you can just "search" it and not have to scan it sequentially when trying to find parents and entries. I'll leave that up to you to find out ;-) Hi, now that I know the context here are some more comments. If the purpose is to create a useful ldif file, which could eventually be used for import then formatting an entry correctly is not enough. Order of entries matters: parents need to come before children. We already handle this in db2ldif or replication total update. That said, whenever you write an entry you always have seen the parent and could stack the dn with the parentid and createt the dn without using the entryrdn index. You even need not to keep track of all the entry rdsn/dns - only the ones with children will be needed later, the presence of "numsubordinates" identifies a parent. Last but not least, since I think dbscan is broken for entryrdn, investigating and fixing this would also be nice I mean the same information can be found in id2entry (?). Or this is not the case and dbscan does the exact same process you just described in order to print "parentid: X" for each entry when you do "dbscan -f id2entry.db"? Thanks again, ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
