directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: ApacheDS partition implementation based on Relational Model
Date Thu, 02 Nov 2006 15:26:04 GMT
On 11/2/06, Alex Karasulu <> 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)
> 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 :
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.


Emmanuel L├ęcharny

View raw message