You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a service which syncs various data from LDAP into a database on a given interval. We sync roughly 50,000 users, and 48,000 groups from LDAP during this process, and it's a hit or miss on the standards for how these will show up. An example of one of the structs that's used as part of the Entry.Unmarshal() process:
The idea is that for the fields which aren't actually defined in the source object within LDAP/AD, those would be nillable within the struct, and I could easily determine if something is set, but an empty string, vs not set (for example).
However, with v3.4.6 today, this results in the following, which means we have to do checks against many fields to see if they are empty (and still can't tell if it was originally set or not):
ldap: expected field to be of type string, []string, int, int64, []byte, *DN, []*DN or time.Time, got *string
Would it be possible to support nillable fields, or is there some lower level protocol issue with doing this?
The text was updated successfully, but these errors were encountered:
I have a service which syncs various data from LDAP into a database on a given interval. We sync roughly 50,000 users, and 48,000 groups from LDAP during this process, and it's a hit or miss on the standards for how these will show up. An example of one of the structs that's used as part of the
Entry.Unmarshal()
process:The idea is that for the fields which aren't actually defined in the source object within LDAP/AD, those would be nillable within the struct, and I could easily determine if something is set, but an empty string, vs not set (for example).
However, with v3.4.6 today, this results in the following, which means we have to do checks against many fields to see if they are empty (and still can't tell if it was originally set or not):
Would it be possible to support nillable fields, or is there some lower level protocol issue with doing this?
The text was updated successfully, but these errors were encountered: