Agreed

If no one is coming up with such a mapping table solution in the next 
one or two days, let's change the column type then and postpone it to 
Horde 4. We really need to fix this before the 3.2.2 release.

I would prefer to have integer userids for Horde whether native or 
not, yes, to make it simpler to write apps that integrate with global 
Horde user information, and to have things like OpenID and OAuth 
server/provider support. As for adding extra joins, things like the 
current user's id would be cached in the session, and we can 
relatively easily cache other flat lists of id => username when 
needed. And joins on simple mapping tables are pretty quick even with 
millions of rows.

I can be convinced not to do this for now I guess, but I think we 
really need a global horde userid, that is an integer, for simplicity 
in Horde 4.

So, do you want to add a mapping table for user shares too? Because we 
use a text field there too, and this table is much more used than the 
group shares table. And isn't an additional join eating up all the 
performance gain we get from using integer indexes?

I feel pretty strongly on the data type issue - I want to start making 
more choices for Horde that lend themselves to better 
scaling/performance, and storing integer ids as strings is not one of 
those. Mapping tables aren't a bit deal especially if we cache 
anything expensive.

I'm still not convinced that introducing yet another mapping table, 
for anything but SQL groups (LDAP, DataTree, custom driver), is a 
better solution that having the group id column a string column. But 
anyway, we have to fix this, because currently the SQL share driver 
simply is broken if not using SQL groups.

Except that if shares are already in SQL, you're not avoiding SQL.
Because it's much more efficient to store it as an int, and to query 
it as an int.

Right. Hmm, probably because this is the referential field to the horde_groups table.
If it will be changed to strings the reference to horde_groups will 
not work anymore, so a different solution is necessary, but of course 
it should not suffer from sync problems.

Sincerly,
Klaus

A mapping table is pretty much against the purpose of using LDAP to 
avoid SQL databases.
Why is the group id in the share tables not a string column?

Yep, some ideas:
a) Maybe we could use the horde_groups table normally used by the sql 
driver for the mapping. There have to be some mechanism for 
synchronisation ith the directory.

b) The second idea is no general solution. Will only work with LDAP 
entries with objectclass posixGroup:

The gidNumber attribute  could be used as "group_id", but this will 
definitly fail with non Posix Groups (e.g. it will fail with Active 
Directory).

So I thing a mapping table would be the more general solution, but 
synchronisation with the Directory Service is probably the largest 
challenge in this approach.

Sincerly,
Klaus

Yup, that'd be a problem. I wonder if we can do a mapping table 
somewhere, to avoid making the group_id field a string?

The problem is the following:

If for example giving permission to a group for a calender, in the 
first step the group ist correctly shown, but after closing and 
reopening the permissions windows a group entry with no name is shown.

The problem seems to be that LDAP identifies the group by their DN, 
but in kronolith_shares_group (as well as the other xxx_shares_group 
tables) a integer field is used for the group_uid field.

After setting permission there is entry in kronolith_shares_group with 
group_uid = 0 which of course could not be resolved back.