From dev-return-8525-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Fri Jun 27 12:56:16 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 28338 invoked from network); 27 Jun 2008 12:56:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jun 2008 12:56:16 -0000 Received: (qmail 91597 invoked by uid 500); 27 Jun 2008 12:56:17 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 91567 invoked by uid 500); 27 Jun 2008 12:56:17 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 91550 invoked by uid 99); 27 Jun 2008 12:56:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 05:56:17 -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 (athena.apache.org: domain of kwsutter@gmail.com designates 209.85.198.233 as permitted sender) Received: from [209.85.198.233] (HELO rv-out-0506.google.com) (209.85.198.233) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 12:55:27 +0000 Received: by rv-out-0506.google.com with SMTP id g37so412127rvb.33 for ; Fri, 27 Jun 2008 05:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=s8YDDswrAq+Olx/jxiz9nCIM0EDoYQNP1kC9R57T4Mc=; b=UAICDOkF3Kap9jqU9s0z7ZCeCSCO+o6wGUp8graqCpbFjarOtLKEvB3A9zzCRjyfMg FXy+5JcTqFLDTxNsVJRM3PV2ZbuyehXbfNJrPktvt1QuW6ImXn2sqtkg7+rJqfYl38Ac or4oHrXkQNpqhN+g8Ctp8V3ZY5lypB0DlJrmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Evgck+ibA7O0/6Pls9UP9dCXw9uyAMdZIEjC/5lHrptxi088ObIMTONULVjFKX6GBs r2VFefJ4PaWXetQpGuMJSW8zLev8TTUbHRYtC7KfmMrtGEGM/IOeS8tB91j9Gom3WAkD 4iKFAfIEKXoB70qXrppYJ7+Tq18AnNk2StSq4= Received: by 10.141.36.10 with SMTP id o10mr735025rvj.176.1214571347117; Fri, 27 Jun 2008 05:55:47 -0700 (PDT) Received: by 10.140.248.21 with HTTP; Fri, 27 Jun 2008 05:55:47 -0700 (PDT) Message-ID: <89c0c52c0806270555m57d61d88x3bb598fc352b47c1@mail.gmail.com> Date: Fri, 27 Jun 2008 07:55:47 -0500 From: "Kevin Sutter" To: dev@openjpa.apache.org Subject: Re: [jira] Closed: (OPENJPA-645) Date millisecond precision lost for Informix IDS and SQLServer In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8113_13848440.1214571347107" References: <1175510760.1214510504977.JavaMail.jira@brutus> <672646852.1214511825154.JavaMail.jira@brutus> <000001c8d7cb$5b269fd0$6677160a@kokako> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_8113_13848440.1214571347107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Should this topic be opened as a separate Issue (or sub-task)? Or, should this Issue just be re-opened? I'm not an expert with this timestamp stuff, but it seems like we still have an open issue with this resolution. Kevin On Thu, Jun 26, 2008 at 4:13 PM, Dinkar Rao wrote: > Ditto for SQLServer. > > On IDS, the fractional precision is specifiable upto only 5 places, as > in "udate DATETIME YEAR TO FRACTION(5)". So the max fractional value > that can be stored is 99999. > > On Thu, Jun 26, 2008 at 1:29 PM, Evan Ireland wrote: > > Just a note on this for Sybase databases, for which the resolution is 1 > > 300th of a second. When using O/R mapping with Sybase ASE, it is best to > > round the Timestamp value to the nearest 100th of a second when storing, > so > > that you don't get unexpected comparison failures when reading the value > > back again or using a value in a 'where' clause. > > > >> -----Original Message----- > >> From: Catalina Wei (JIRA) [mailto:jira@apache.org] > >> Sent: Friday, 27 June 2008 8:24 a.m. > >> To: dev@openjpa.apache.org > >> Subject: [jira] Closed: (OPENJPA-645) Date millisecond precision lost > for > >> Informix IDS and SQLServer > >> > >> > >> [ https://issues.apache.org/jira/browse/OPENJPA- > >> 645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > >> > >> Catalina Wei closed OPENJPA-645. > >> -------------------------------- > >> > >> Resolution: Fixed > >> > >> fix checked in under r672017 > >> > >> > Date millisecond precision lost for Informix IDS and SQLServer > >> > -------------------------------------------------------------- > >> > > >> > Key: OPENJPA-645 > >> > URL: > https://issues.apache.org/jira/browse/OPENJPA-645 > >> > Project: OpenJPA > >> > Issue Type: Bug > >> > Components: jdbc > >> > Reporter: Dinkar Rao > >> > Priority: Minor > >> > Attachments: patch-645.txt > >> > > >> > > >> > An entity has an attribute of type java.util.Date, annotated with > >> @Temporal(TemporalType.TIMESTAMP): > >> > @Temporal(TemporalType.TIMESTAMP) > >> > public Date udate; > >> > This gets mapped in Informix to a column of type: > >> > udate DATETIME YEAR TO FRACTION (3) > >> > and in SQLServer to > >> > udate DATETIME > >> > When the udate attribute is assigned a value with millisecond > precision, > >> say "12:34:56:789", OpenJPA chops off the millisecond fractional part > when > >> it generates the INSERT statement. > >> > In DBDictionary, for this type, we come to setDate() with the 'val' > >> parameter set to the correct java.util.Date value "12:34:56:789". (The > >> millisecond value is stored in the (Gregorian.Date) cdate.millis > attribute > >> of java.util.Date). setDate() then calls setTimestamp() - the last else > - > >> with a new instance of java.sql.Timestamp: > >> > setTimestamp(stmnt, idx, new Timestamp(val.getTime()), null, col); > >> > java.sql.Timestamp is made up of 2 parts - a date part that stores the > >> time upto seconds, and a separate attribute, called nanos, that stores > >> everything that is fractional of seconds. > >> > So the new Timestamp value that is sent to setTimestamp() has this: > >> > (Gregorian.Date) cdate = 12:34:56 > >> > nanos = 789000000 > >> > In setTimestamp() there is a check for supportsTimestampNanos. Because > >> in the InformixDictionary and SQLServer dictionaries this is set to > false, > >> the code then zeros out the nanos field: > >> > if (supportsTimestampNanos) > >> > val.setNanos(nanos); > >> > else > >> > val.setNanos(0); > >> > Consequently, all fractional seconds information is lost for these 2 > >> database types from the INSERT statement for this timestamp value. > >> > The nanos field in java.sql.Timestamp does not really mean that only > >> nanoseconds are stored there - it means that any fractional value, after > >> seconds will be stored there.This problem happens not only with the > Date > >> field in the entity, but also with java.util.Calendar and > >> java.sql.Timestamp. The solution is to always set the nanoseconds value > in > >> the (java.sql.Timestamp)val field. The check for supportsTimestampNanos, > >> as well as the flag itself, is not needed, because both IDS and > SQLServer > >> do allow fractional seconds. > >> > Will attach a patch ASAP. Albert has reviewed the proposed solution. > >> > >> -- > >> This message is automatically generated by JIRA. > >> - > >> You can reply to this email to add a comment to the issue online. > > > > > > > ------=_Part_8113_13848440.1214571347107--