On 02/11/2010 05:01 AM, Pavel Zůna wrote:
My point is that for binary objects we were explicitly setting their
type to str. We don't seem to be doing that any more, so are we
relying on python-ldap to default to the str type? It's ok if we do
I'd just like to see a comment to that effect in case something
changes in the future.
Yeah, we do rely on python-ldap in this case. It returns everything as
str. I didn't realize you were referring to the changes in the Encoder
class.
Some background information about Encoder:
When I started working on the ldap2 backend, I realized that around
every call to python-ldap, we had to encode/decode both compound and
scalar values. With scalar values, it wasn't a problem to just choose
what to encode/decode and what not. With compound values likes entries,
it was more difficult, because all attributes are returned as str, but
have different types. I implemented a feature in the Encoder class, that
enabled its consumers to define a decoding table for dicts and a
function of the dict key, that would return a key in the decoding table.
The decoding table was supposed to contain callables (mostly python
types), that would be used to decode the dict value. If the returned key
was not in the table, default decoding (to unicode) would take place.
The idea was, that we would convert boolean strings to bool, integer
values to int and leave binary values as str. Unfortunatly, there were
some difficulties with boolean types, then Simo chimed in about integers
in LDAP not having the same range as int in python and you can't argue
with Simo. Plus I didn't really feel like doing anything about the
booleans, so the decoding table in ldap2 was just used to leave binary
attributes as str. With the latest Encoder patch, I decided to remove
the decoding table completely and replace it with a dont-decode function
of the dict key, because that's just what we need in ldap2 and the
decoding table wasn't working properly with complex compound types
anyway (e.g. dicts in a dict).
Having some type of table driven mechanism which maps an LDAP attribute
to it's corresponding Python type sounds like the right approach. It's
essential the LDAP attribute expressed as a string be parsed into the
correct Python type.
Where does this mapping come from? Well, I thought we used the schema to
perform this mapping. In fact I fixed a bug in this code recently where
the type conversion was not happening because the schema hadn't been loaded.
Given the schema defines the type, we load the schema and use it to do
type conversions, then that leaves confused as to what the issue is.
There must be something else I'm missing, can you fill me in?
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
