Using serialization may present issues when trying to figure out how to
create indices that allow for correct sorting to evaluate ordering assertions
like for example:

(foo > 2.95)

Just a thought.  There's got to be existing data types out there in LDAP
that map well to Java types that are part of existing published schemas.


On 6/21/07, Emmanuel Lecharny <> wrote:
Ole Ersoy a écrit :

>> Ok, now, I would say that you should simply store int, long, float,
>> etc instead of the associated classes.
> Oh Yeah - Sorry I should have distinguished between primitives and
> classes.  I really meant the primitives.  Originally I was just
> planning on using the AcceptAllSyntaxChecker for all the java types,
> and then I would just convert them back to whatever they are after
> they cross the wire and arrive at the client.  So I tried it out, and
> I noticed that all the values come back in hex.  I could convert from
> hex to the corresponding java type, but then I thought "What about
> queries?".  So I figured I'd better map them to LDAP syntaxes, so that
> queries go OK.  So integers map fine, but if someone wanted to query
> on decimals?  Probably a low utility scenario, but I think a lot of
> people would be "Pleased" if their decimals could be handled by the
> server.  I looked at rfc2252 and it sort of looks like LDAP has
> decided to leave decimals to RDBs.  The only thing that looks like it
> might fit is "Numeric String".  Thoughts?

I would say that you should store float and double as serialized data,
and desearialize them. That mean, use Float and Double (they implement
serializable, which is not natively supported by double and float). It
cost much more time that doing it yourself, but who cares ? As you
mentioanned beofre, 98% is String, 1% int, and the remaining is barely
totaly boolean.

Just focus on 99.9 % of the cases, let the 0.1% to freaks :)

> Thanks,
> - Ole