Hi,

On 11/2/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> On 11/2/06, Alex Karasulu <aok123@bellsouth.net> wrote:
> > Ersin Er wrote:
> > <snip/>> How can we map Attributes to SQL model?
> >
> > There are probably a few ways to do this but some will be much faster
> > however the faster it is the uglier it will be.
> >
> > One way is to have one big table with the following columns:
> >
> > 1). ENTRY (BLOB)
> > 2). NDN (VARCHAR)
> > 3). UPDN (VARCHAR)
> > 4). ID (INTEGER)
>
> Well, from a RDBMS point of view, I think that a correct structure will be
> something like  :
> A first table, ENTRY_T, with those columns :
>
> DN : varchar (but may be an id, which will refer to another table)
> ATTR : attribute name, varchar
>
> and an ATTRIBUTES_T table :
> DN : varchar
> ATTR : varchar
> VALUE : blob

This was the schema I thought. But I am really not sure. This
discussion is going interesting and that's good.

> The idea is that yoiu will set index on those table, so you don't need
> anymore to declare NDN.
> For instance, if you want to get all attribute values for an entry, then the
> request will looks like :
> select DN, ATTR, VALUES from ATTRIBUTES_T where DN = %dn%
>
> (%dn% stand for the DN you are looking for)
>
> Now, if you want all the entries which cn = ACME, the request will be :
>
> select DN, ATTR, VALUES from ATTRIBUTES_T where DN in (select DN from
> ATTRIBUTES_T where ATTR = 'cn' and VALUE = 'ACME')
>
> Just set the correct index to have good performances !
>
> (this is just a first approach, we need to improve it a _lot_)
>
> I have put some thought related to backend organization here :
> http://docs.safehaus.org/display/APACHEDS/Backend
> but it needs to be further a lot !
>
> > You can lookup entries that are blobs this way by normalized (NDN) and
> > user provided distinguished names (UPDN) as well as by ID.
> >
> > If you want to index a specific attribute use some DDL to add a new
> > COLUMN to this table.  That column should be the name of the attribute
> > being (LDAP not DB) indexed.  Do a full table scan the first time and
> > populate this new "index" COLUMN with the values of the attribute.
> >
> > Handling queries now is not that complex.  Basically you need to
> > determine which attributes you have indices on and which you don't.
> > Then do a query to select and narrow down the rows that you'll have to
> > resusitate the entry from the blob from.
> >
> > You might need another table for an existance index too.  The EXISTANCE
> > table might have a ATTRIBUTE column, and ID column.  If a record exists
> > in this table for an attribute your blobed entry then has a value for
> > this attribute.
> >
> > Should we hold Attribute
> > > Values in blobs?
> >
> > You will need to hold the entry in a blob.
>
>  Well, you have two options : varchar for simple and limited entries (but
> varchar can't be larger than, say, 256 chars, which may become a problem, or
> blobs, for binary elements or big chars. That's a pitty because blobs sucks
> when you want to set index on them.
>
> > > Can we leverage the power of SQL SELECT for LDAP search operations?
> >
> > Sure.  You just need to know how to build the WHERE clause of SQL using
> > this simple schema.
> >
> > > How much of the partition code in ADS can be used for this task?
> >
> > Not much.
>
> Yes, this will be really  one of our biggest problem.
>
> > Alex
> >
> >
>
>
>
> --
> Cordialement,
>  Emmanuel Lécharny

We need to document our ideas. I think we will reach a good point
soon. Or we'll see it after implementation.

Thanks!

-- 
Ersin