Postgre Adapter: better handling of timestamps

[marcosdsanchez]

Better handling of timestamps
See #126 for other improvements

[VexedPanda]

Fixes timestamps

[VexedPanda]

I don't use postgre. Anyone else think this is good to commit?

[basilieus]

Yes this can be committed, this shares the same code as MySql adapter for timestamps.

I think the DateTime? is used for DateTime? fields.

[VexedPanda]

(In [67]) Fixes #171

[tompalan]

I think this patch does not work:
As there is no datetime type in postgres  http://www.postgresql.org/docs/8.4/static/datatype-datetime.html, the timestamp type is used for saving a "date & time".
That's the difference to MySql, where both a datetime & timestamp exist, the timestamp-type is used as "System-generated Timestamp", and the datetime as generic date/time type.

I needed to revert this patch to get the postgres-adapter running correctly.

[disaster]

please revert this patch, as it makes unusable postgresql for "datatime" fields.
I think that optimistic locking should be based on a "magic" column name, and not on a field being "timestamp" which is something that exists just on  mysql (and which differs from datetime only for his validity range)
In postgres there is no such difference:  http://www.postgresql.org/docs/8.4/static/datatype-datetime.html

This change has been introduced in  qcubed:
As is the case with most DB vendors, Qcodo intending that TIMESTAMP be a special-use column used to assist with optimistic locking (which Qcodo now fully supports).

If you want I'll write a patch to move the optimistic locking support to "magic column name" instead of current TIMESTAMP type column

[VexedPanda]

Any patches would be more than welcome. :)

[olegabr]

This patch makes timestamp type unusable for PostgreSQL users.

The problem with Optimistic Locking technique in this context is it's implicitness. The solution should be to make it explicit. I suggest to use includes/configuration/codegen_settings.xml file to explicitly list tables and it's columns that should be affected by the Optimistic Locking technique. For example:

<OptimisticLocking pattern="" list="request.timestamp,session_data.timestamp"/>

In order to preserve the backward compatibility, the absence of such a line in the codegen_settings.xml file should be treated as an implicit OL for timestamp columns.

In the default version of codegen_settings.xml it should be simply:

<OptimisticLocking pattern="" list=""/>

It would blocks the implicit usage of OL, and documentation for OL should state that one needs to comment it out in order to obtain the implicit behaviour.