Hi Rainer,
I tried your hint but it did not work out. The problem is that postgre
really stores microseconds unless one does not restrict it. If I create
the seqtime field as "timestamp(3) without time zone" and apply your
date-time pattern ( ...mm:ss.SSS) it works, but by default postgre
stores 6 precision digits. I think the java.sql.Timestamp can handle
times up to nano-seconds, but I don't think the java.util.Date does (?).
At least I have not encountered a case where I really liked to have a
more accurate timestamp than milliseconds, so one could let the
postgresqldriver always create the restricted version of the timestamp ...
kind regards,
Eike
On 29.06.2010 11:24, Eike Kettner wrote:
Hi Rainer,
I did not know about the SQL_DATETIME_PATTERN - this sounds very
promising. I will try this and let you know.
I've still opened a jira issue for that, before I read this mail.
Thank you and kind regards
Eike
On 29.06.2010 10:00, Rainer Döbele wrote:
Hello Eike,
I have not started a deep investigation but I could imagine that
supplying a modified SQL_DATETIME_PATTERN would solve this.
Currently the function getSQLPhrase(int phrase) on
DBDatabaseDriverPostgreSQL returns the following pattern which does
not include milliseconds:
case SQL_DATETIME_PATTERN: return "yyyy-MM-dd
HH:mm:ss";
you could now override getSQLPhrase() and add the milliseconds
similar to this:
case SQL_DATETIME_PATTERN: return "yyyy-MM-dd
HH:mm:ss.SSS";
This should hopefully add the milliseconds to the constraint.
Let me know if it helped so that we can correct this in our
implementation.
Regards
Rainer
Eike Kettner wrote:
re: DBSequence Table and PostGre
Hello there
I think I found a bug in DBSeqTable#getNextValue():
I use postgre sql and getting the next sequence value, the
getNextValue() goes into an endless loop. It fails when updating the
sequence value and therefore tries again and again and again...
It cannot update the sequence because postgre sql stores milli and
nanoseconds within the timestamp. The WHERE clause from the update omit
the milli and nanoseconds. So it tries to update ... WHERE
timestamp='2010-06-10 14:22:24' but in DB it is '2010-06-10
14:22:24.21231'. The update fails and the loop does never stop. It
would be great to be informed somehow if the loop goes beyound some big
value. I did not dig into this deeper, I'm using a quick workaround
that saves the time as a long (override getNextValue()).
kind regards,
Eike
