Hi, On 11/2/06, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
On 11/2/06, Alex Karasulu <[EMAIL PROTECTED]> 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
