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
>
>
>
