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

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