On 2/15/07, Exell E. Franklin J. <[EMAIL PROTECTED]> wrote: > > Hello to all. > First i apologise for english sorry. > ¿if anybody could help me? i will thank you. > > I was seeking some ldap ports examples like msql, as > Vivien and Rodrigo recomended me. > > Now i'm writing a libgda ldap port implementation > and i am stay on gda-ldap-recordset and writing the > following funtions: > > fetch_row & > gda_ldap_recordset_get_n_rows > > I'm think that fetch_row is to get a row's info and > gda_ldap_recordset_get_n_rows isto get the rows > cant.
Right. Since GdaLdapRecordSet inherits GdaDataModelRow, it must implement its virtual functions. > > I know that ldap is not a data base like *sql is > a «directory entries». > > When i am searching with LDAP API functions a server > can send me three different types of results back to > the client: > * Directory entries found by the search. > * Any search references found within the scope > of the search (a search reference is a reference > to another LDAP server). > * An LDAP result code specifying the result of > the search operation. > Where the results are represented by LDAPMessage > structures. > > The server returns the search results as a chain of > LDAPMessage structures. Each structure contains an > entry, a search reference, or an LDAP result code. > To access data from entries found by the search, i > need to follow this general process: > > 1. Get each entry in the results. > 2. Get the attributes from each entry. > 3. Get the values from each attribute. > > But i can see the results as a table that have one > column and n rows.where each row could be a pointer > to two mores tables a table that represents > attributes > and other table that represents a values. > > Or i can see the results as a table that have one > column and n rows.where each row could be a only > a informations pointer. > > > if i use that, then with > gda_ldap_recordset_get_n_rows > get the rows from the eqiv. table > & with fetch_row i could get the «information's > pointer» or table's pointer to table's attributes > and table's values from entries. > > My quetion is: > ¿is a good vision from that ?. > ¿anybody has other thinks? > ¿some ideas? > Thanks for you attention. > Rergards to all. The LDAP has a lot of commented code (because it was obsolete with the new API), does what you want to do correspond to what the commented code did? If so, then I believe it's Ok. I don't know much of LDAP, but when I use it, I can get lists of people with their name, email, phone, etc. I guess a good approach would be to return a data model where the rows are one for each person in the LDAP result, and the columns are name, email, phone, ... Now, I don't know how queries should be formatted, but maybe it's possible to map some SQL on top of some "virtual" tables (for example MDB tools implements its own SQL engine on top of the data stored in the .MDB files). So maybe there could be a query like "SELECT name, email FROM organisation_people". I hope this helps... Cheers, Vivien _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
