Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 66636 invoked from network); 5 Sep 2009 21:51:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Sep 2009 21:51:39 -0000 Received: (qmail 46804 invoked by uid 500); 5 Sep 2009 21:51:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 46722 invoked by uid 500); 5 Sep 2009 21:51:38 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 46714 invoked by uid 99); 5 Sep 2009 21:51:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 21:51:38 +0000 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=HTML_MESSAGE,SPF_PASS,SUBJECT_FUZZY_TION X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.210.181 as permitted sender) Received: from [209.85.210.181] (HELO mail-yx0-f181.google.com) (209.85.210.181) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 21:51:28 +0000 Received: by yxe11 with SMTP id 11so3667997yxe.15 for ; Sat, 05 Sep 2009 14:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=QAfhYQOv0OcewkLxFLK6JM7YWzkM6DzCFN7XRgTWsFU=; b=o77Dd/QcalQ6KSPPiyjuQfKHzMMFckcOMDwVYBHCViRceqdYlSTIVi/VUGfCgPgl7z thdKf2xHmc46oQObSAZniPKjcVv1A9YGorBKUZ/gIx1RunCsrcKIwN1/5wQ0awFFuhGv xHERWJek0cDvpR69KCZbbX+ULI4laFFVy7F7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=abYfmw70jsgBYex3whczjRPhM5YTzVVICbBGnhCREFiVc+kefUQYVj8SxZHRG0RWSy t8S6uIIhVCRX9Rtxa8WkZ5v0F43DLJjSC0NMbTxYVzDSK86fnEsuxGUk68NklwiVMuJ5 7of/ZhUtRPdVS1ih4ipTrb6sKEF6GDUPQnsvw= MIME-Version: 1.0 Received: by 10.100.80.2 with SMTP id d2mr13966296anb.35.1252187466946; Sat, 05 Sep 2009 14:51:06 -0700 (PDT) In-Reply-To: <4AA2DBDD.20205@nextury.com> References: <4AA29AA5.8020108@nextury.com> <4AA2DBDD.20205@nextury.com> Date: Sun, 6 Sep 2009 00:51:06 +0300 Message-ID: Subject: Re: [LDIF partition] File names From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0050450176f428d7c50472db9d70 X-Virus-Checked: Checked by ClamAV on apache.org --0050450176f428d7c50472db9d70 Content-Type: text/plain; charset=ISO-8859-1 OK then let's carry on if you can whip this together that fast let's do it. Alex 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 :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --0050450176f428d7c50472db9d70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK then let's carry on if you can whip this together that fast let'= s do it.

Alex

On Sun, Sep 6, 2009 = at 12:45 AM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Alex Karasulu wrote:
I think it's a waste of time trying to force fit the FS namespace to th= e
LDAP namespace. =A0I think we should just load LDIF files if they exist in = or
below some partition directory. =A0They can contain any LDIF and have any number of LDIF entries in them. =A0It'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 th= e
FS to have a partition that reads and uses LDIFs.
=A0

Atm, what the LdifPartition should do is really to be able to support the S= chemaPartition.

That mean : manipulating Ldif files with one entry =3D one file.

Also the current LdifPartiton, as it has been written, does not support any= thing but a FS image of the Dit structure.

We can think about dropping a big Ldif file into a directory, and expect th= e LdifPartition to deal with it, even if it means updating or adding an ent= ry in the middle of a 10 Mb file, with all the consequences it has like dea= ling 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 wo= rking 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 p= ick a file to store a new entry in.

In other words, right now, with the existing code, which is an exact replic= ation of the DIT structure, I see no other ways to go but to do :
1 entry =3D 1 ldif file
and
entry RDN =3D> 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 m= ail 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 w= hich 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 Blo= g :: http://www.jroller.com/a= karasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

--0050450176f428d7c50472db9d70--