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
