the fix for this ticket is required to complete ticket #346

attachment
0001-Ticket-47369-provide-default-syntax-plugin.patch

Why do we need #define PSEUDO_ATTR_DEFAULT_SYNTAX_OID "2.16.840.1.113730.3.1.2210" and #define PSEUDO_ATTR_DEFAULT_SYNTAX "pseudo#attr#defaultsyntax" ? For the OID, can't we use "1.1"? And do we really need an attribute name? Introducing another attribute like this is problematic for two reasons

1) this attribute name violates attribute name syntax
2) this attribute will be replicated, which will cause headaches for older versions

The OID is used to add the plugin to the oid syntax hash table, so I was trying to use one which is not already used, but using "1.1" would be the more elegant solution.

The syntax name is used to add the plugin to the syntax name hashtable and to locate it when no entry for the "real" attribut is found, it is only an attribute name, there never will be a an attribute with this name, so it will not be replicated.
The name should not conflict with any real attribute name, so the violation of the attribute name syntax was intentional, just as in the unhashed#password case, so there never will be a conflict with a real attribute name.

Replying to [comment:7 lkrispen]:

The OID is used to add the plugin to the oid syntax hash table, so I was trying to use one which is not already used, but using "1.1" would be the more elegant solution.

The syntax name is used to add the plugin to the syntax name hashtable and to locate it when no entry for the "real" attribut is found, it is only an attribute name, there never will be a an attribute with this name, so it will not be replicated.

Yes, it will be replicated, and it will cause problems.

The name should not conflict with any real attribute name, so the violation of the attribute name syntax was intentional, just as in the unhashed#password case, so there never will be a conflict with a real attribute name.

Having unhashed#user#password as a real attribute caused problems with replication and migration. That's why we had to remove it.

The syntax name is used to add the plugin to the syntax name hashtable and to locate it when no entry for the "real" attribut is found, it is only an attribute name, there never will be a an attribute with this name, so it will not be replicated.

Yes, it will be replicated, and it will cause problems.

No, it cannot be replicated, it does not exist as an attribute. It is only a name to do syntax lookup if the lookup for a real attribute name fails.

Replying to [comment:9 lkrispen]:

The syntax name is used to add the plugin to the syntax name hashtable and to locate it when no entry for the "real" attribut is found, it is only an attribute name, there never will be a an attribute with this name, so it will not be replicated.

Yes, it will be replicated, and it will cause problems.

No, it cannot be replicated, it does not exist as an attribute. It is only a name to do syntax lookup if the lookup for a real attribute name fails.

{{{

1344                    slapi_add_internal_attr_syntax( PSEUDO_ATTR_DEFAULT_SYNTAX, 
1345                                            PSEUDO_ATTR_DEFAULT_SYNTAX_OID, 
1346                                            DIRSTRING_SYNTAX_OID, 0,  
1347                                            SLAPI_ATTR_FLAG_NOUSERMOD| 
1348                                            SLAPI_ATTR_FLAG_NOEXPOSE);

}}}

This will add PSEUDO_ATTR_DEFAULT_SYNTAX to the schema and it will be replicated.

maybe I still miss something, but in my understanding the call path is
slapi_add_internal_attr_syntax --> attr_syntax_add --> attr_syntax_add_by_name|oid --> PL_HashTableAdd

so it will not add anything under cn=schema, it is the same path as used when reading in the schema, just from an internal source

Replying to [comment:11 lkrispen]:

maybe I still miss something, but in my understanding the call path is
slapi_add_internal_attr_syntax --> attr_syntax_add --> attr_syntax_add_by_name|oid --> PL_HashTableAdd

so it will not add anything under cn=schema, it is the same path as used when reading in the schema, just from an internal source

Right. So when someone does a search for cn=schema, it will show up. When schema replication happens, it will be sent with the other schema. Both of those will cause problems.

attachment
0001-Ticket-47369-version2-provide-default-syntax-plugin.patch

ok, I missed that a schema search does an enumeration of the asi hashtable, and the pseudo attr is visible by a search. I think the schema csn is not upddated and so it probably will not get replicated, but I implemented a new version, which is local and does not call attr_syntax_add.

New patch attached

I guess I just don't understand why there has to be a default attribute with a name, and why it has to be in the oid and attrname tables? Can't you just create a default one and return that when any of the lookups fail?

But that's what I'm doing now:

static struct asyntaxinfo *default_asi = NULL;
....
asi = attr_syntax_get_by_name_locking_optional(name, PR_TRUE);
if (asi == NULL)
asi = attr_syntax_get_by_name(ATTR_WITH_OCTETSTRING_SYNTAX);
if ( asi == NULL )
asi = default_asi;
....
I'm just using attr_syntax_create to set it up and then set the plugin functions. It does not add anything to the tables. maybe creating a full asi structure is too much overhead, but callers expect an asi and I wanted to avoid adding another function.
But I can strip down the asi initialization further in a new attr_syntax_create_default()

Ok, I see. Sorry, I thought the code was adding to the hash tables.

$ git merge ticket47369
Updating 2c88c96..d779853
Fast-forward
ldap/servers/slapd/attrsyntax.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 187 insertions(+)
$ git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 2.72 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
2c88c96..d779853 master -> master

git push origin 389-ds-base-1.3.1
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 2.78 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
1b7135c..62d0dbf 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

git patch file (1.2.11) -- needed for backporting Ticket #346 "version 4 Slow ldapmodify operation time for large quantities of multi-valued attribute values"
0003-Ticket-47369-version2-provide-default-syntax-plugin.patch

ack

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1109373

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/706

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.