[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-sql insert: entry at root denied

Brad Midgley wrote:


I was hoping to preserve the view. The data is being changed by sybase clients and I'd need to set up the appropriate triggers to update it. That is an option I'll consider though.

This version of sybase does not support union in a view. I already looked down that avenue.

This would be the most appropriate way to handle this type of configuration.

From reading the code, I started to think it was possible to do without the parent in the db. The suffix entry is not found, but down later in that section of code is

if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
 || !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e ) )
{ ... } else {
    parent_id.eid_id = 0;

The meaning of this test is: "adding an entry without a parent is something very special", so it has to be possible only for special users or in special circumstances. I undrestand back-sql is all special, so I wouldn't mind a configure option that says: "let everybody add entries without a parent" (of course provided ACLs grant them entry write access). Someting like

   allow_orphans    {NO|yes}

so that the test would become

if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
|| !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e ) && !bi->bi_allow_orphans )
{ ... } else { /* ^^^^^^^^^^^^^^^^^^^^^^^^ */
parent_id.eid_id = 0;

also, an empty insentry_query should mean that no modifications of the ldap_entries table should be attempted (sort of implying that a view is used, or a trigger for modifications at the RDBMS side is in place).

So I was thinking I could coax it to take that branch and assume the parent has the id 0 even though it wasn't found. Does this approach have implications that make it too messy or painful?

The main implication is that you'd be allowed to create orphaned entries, i.e. entries without a "real" parent, just rooted at somewhere that does not exist, or, even worse, that exists, but it's not exactly one level above in the tree structure. I also note that another drawback of not having a real entry for the database suffix is that the search optimizations that I'm working at will break the current behavior, i.e. subtree searches will require the search base to exist. I guess right now you can search your database even if the suffix entry does not exist (but you cannot do onelevel searches). This is going to be no longer possible shortly (in HEAD; perhaps a bit later in RE22).

I have insentry_query set to "" in my config. I could test for that empty value if necessary when handling add or modrdn. Or I could set insentry_query to some kind of no-op that accepts four parameters, but I certainly prefer to have any patches I make accepted upstream. I don't think you'd want the blind assumption that if the parent isn't found we can just use an id of 0.

I guess SQLPrepare()ing and SQLBindParameter()ing with respect to an empty string may not be a Good Thing, but as long as your RDBMS doesn't complain that should be fine.

Another approach I'm considering, based on the usage many people I assume are doing of back-sql, is to provide a "fake" in-memory suffix entry, with the rest of the database being flat and based on a single view for the rest of the entries. Something much like the good old back-passwd...


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497