Re: Trying to understand entryrdn.db

Nishan Boroian <085aisv@xxxxxxxxx> · Fri, 4 Aug 2017 08:37:50 -0400

Ok, thanks for the update. 

On Aug 4, 2017 at 08:08, <Ilias Stamatis> wrote:

Okay, now that I have read and understood dbscan's code, I have a few more questions.

2017-08-03 10:10 GMT+03:00 Ludwig Krispenz <lkrispen@xxxxxxxxxx>:

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.

Is it guaranteed that parents are going to appear before children in id2entry.db? 

If so, here's what could probably work: 

- Start reading entries from id2entry sequentially. 
- For each entry, if it has a numSubordinates attribute it means it is a parent for other entries. So we can store it's ID - DN pair in a hash map. 
- For entries that they have a parentid and so we need to figure out their parent's DN, we just look for hashmap[parentid].

To make it even more efficient (if really needed though, because it will make things more complicated) we can store the value of numSubordinates with each parent as well somehow in the map. Every time a parentid is looked in the map we can decrease the value of numSubordinates by 1. When it becomes 0, it means there are no more children of this ID so we can safely remove it from the map. 

However, I don't know if we would really need this last thing. In a 100 million entry db how many parents would we expect to have approximately?

Also, do we have a hash map implemented somewhere?

If parents are not guaranteed to appear before children in id2entry.db, then we would have to alter the above strategy.

Thanks!

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx