Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 10605 invoked from network); 23 Jun 2007 11:47:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jun 2007 11:47:46 -0000 Received: (qmail 1842 invoked by uid 500); 23 Jun 2007 11:47:48 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 1814 invoked by uid 500); 23 Jun 2007 11:47:48 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 1792 invoked by uid 99); 23 Jun 2007 11:47:48 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jun 2007 04:47:48 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 64.233.162.227 as permitted sender) Received: from [64.233.162.227] (HELO nz-out-0506.google.com) (64.233.162.227) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jun 2007 04:47:44 -0700 Received: by nz-out-0506.google.com with SMTP id i1so928160nzh for ; Sat, 23 Jun 2007 04:47:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NoDRFRKbnDuRUcVjpChvoidCi+8FCbCHN5z1Pd/ixA7HHifnBRkwFHzF0j4LufnUKzI4tij/RcAaxvphcCstNndJNdye4XS+eIQ/4DFuweX6rFUqUyhSHG2UPo7/1ZAjxvv83guuida8k+oyxTTHHxrYVD0mPniog3e8WvQ+Ipk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gc3KN3gK75A8z3b35FcTXGmDB3Dd4La3wgzTz+rpqW7g4hDOArsQh8osQH1KpkJ34Ct35OCuka59d2lcYbqn4bTZHVDD0wLsgTgNFAQErSR+ai5d0AES9KGVlOQ+ynOjL306o3cn7wNMRAX757gYksxn7X3qbfvGSLyapui1rZY= Received: by 10.142.157.15 with SMTP id f15mr77961wfe.1182599243265; Sat, 23 Jun 2007 04:47:23 -0700 (PDT) Received: by 10.142.77.21 with HTTP; Sat, 23 Jun 2007 04:47:23 -0700 (PDT) Message-ID: Date: Sat, 23 Jun 2007 13:47:23 +0200 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [Java to LDAP Type Mapping] Double, Long, etc. In-Reply-To: <4679A76E.7000005@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_107595_4669083.1182599243257" References: <467970BB.5030707@gmail.com> <46797AD5.6000502@apache.org> <4679809E.5000300@gmail.com> <4679A76E.7000005@apache.org> X-Google-Sender-Auth: aaae240935c8ebb6 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_107595_4669083.1182599243257 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 wrote: > > Ole Ersoy a =E9crit : > > >> 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 > > > > ------=_Part_107595_4669083.1182599243257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Using serialization may present issues when trying to figure out how to
= create indices that allow for correct sorting to evaluate ordering assertio= ns
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 < elecharny@apache.org> wrote:
Ole Ersoy a =E9crit :

>> Ok, now, I w= ould 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
> cla= sses.  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 trie= d 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 th= em 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 thi= nk a lot of
> people would be "Pleased" if their decimals c= ould be handled by the
> server.  I looked at rfc2252 and i= t sort of looks like LDAP has
> decided to leave decimals to RDBs.  The only thing that = looks like it
> might fit is "Numeric String".  T= houghts?

I would say that you should store float and double as seria= lized data,
and desearialize them. That mean, use Float and Double (they= implement
serializable, which is not natively supported by double and float). It<= br>cost much more time that doing it yourself, but who cares ? As you
me= ntioanned 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 f= reaks :)

>
> Thanks,
> - Ole
>


------=_Part_107595_4669083.1182599243257--