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. Alex On 6/21/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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 >
