directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [Java to LDAP Type Mapping] Double, Long, etc.
Date Sat, 23 Jun 2007 11:47:23 GMT
Using serialization may present issues when trying to figure out how to
create indices that allow for correct sorting to evaluate ordering
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
> >

View raw message