directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [LDIF partition] File names
Date Sat, 05 Sep 2009 21:51:06 GMT
OK then let's carry on if you can whip this together that fast let's do it.


On Sun, Sep 6, 2009 at 12:45 AM, Emmanuel Lecharny <>wrote:

> Alex Karasulu wrote:
>> I think it's a waste of time trying to force fit the FS namespace to the
>> LDAP namespace.  I think we should just load LDIF files if they exist in
>> or
>> below some partition directory.  They can contain any LDIF and have any
>> number of LDIF entries in them.  It's up to the server to track files and
>> contents.
>> This way there is no constraint on users to manage any kind of layout on
>> the
>> FS to have a partition that reads and uses LDIFs.
> Atm, what the LdifPartition should do is really to be able to support the
> SchemaPartition.
> That mean : manipulating Ldif files with one entry = one file.
> Also the current LdifPartiton, as it has been written, does not support
> anything but a FS image of the Dit structure.
> We can think about dropping a big Ldif file into a directory, and expect
> the LdifPartition to deal with it, even if it means updating or adding an
> entry in the middle of a 10 Mb file, with all the consequences it has like
> dealing with concurrent access, and performances issues. But atm, this is
> *not* what the LdifPartition code does.
> And doing that does not solve the problem of having to pick the right file
> in which we have to update an entry, assuming a user dump 10 ldif in the
> working directory, as we have no link between an entry in memory and the
> Ldif file it is stored in. Nor we have any mechanism to generate a file or
> to pick a file to store a new entry in.
> In other words, right now, with the existing code, which is an exact
> replication of the DIT structure, I see no other ways to go but to do :
> 1 entry = 1 ldif file
> and
> entry RDN => file name.
> with a best effort to get a name which covers 99% of the limitations.
> Like it or not, but a minimal handling of the few cases I mentioned in my
> mail will be a matter of two hours, tests included, when any other solution
> will cost a couple of days, at least, as we already have an existing code
> which does 90% of what we need.
> Being a good or bad idea to mimic the DIT structure is irrelevant atm,
> IMHO. We can discuss the pros and cons of it later.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::

View raw message