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
