Re: Trying to understand entryrdn.db

Ludwig Krispenz <lkrispen@xxxxxxxxxx> · Fri, 04 Aug 2017 15:03:42 +0200



    On 08/04/2017 02:08 PM, 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? 

            
    no. that's what I said before, it is possible that parentid >
    entryid. It happens if an entry is moved by modrdn to aother subtree

    
            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

    
    -- 
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx