Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Timestamp support with postgres [SPR-16719] #21260

Closed
spring-projects-issues opened this issue Apr 12, 2018 · 3 comments
Closed

Improve Timestamp support with postgres [SPR-16719] #21260

spring-projects-issues opened this issue Apr 12, 2018 · 3 comments
Assignees
Labels
in: data

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Apr 12, 2018

Arnaud Mergey opened SPR-16719 and commented

I was facing this "seem to be" famous issue by setting a timestamp binding against postgres.

Following test fails with ERROR: could not determine data type of parameter $1

@Test
public void testGetCurrentDate() {

    NamedParameterJdbcTemplate template = new NamedParameterJdbcTemplate(datasources.get(dbType));

    PlatformTransactionManager manager = new DataSourceTransactionManager(datasources.get(dbType));

    final Timestamp ts = new Timestamp(System
            .currentTimeMillis());

    new TransactionTemplate(manager).execute(new TransactionCallbackWithoutResult() {

        @Override
        protected void doInTransactionWithoutResult(TransactionStatus status) {
            template.update("create table test_timestamp (col timestamp)", Collections.emptyMap());
            template.update("insert into test_timestamp (col) values (:TS) ", Collections.singletonMap("TS", ts));
        }
    });

    Assert.assertEquals((Integer) 1, new TransactionTemplate(manager).execute(new TransactionCallback<Integer>() {

        @Override
        public Integer doInTransaction(TransactionStatus status) {
            MapSqlParameterSource paramsSource = new MapSqlParameterSource();
            paramsSource.addValue("TS", ts, Types.TIMESTAMP, "timestamp");

            return template.queryForObject("select 1 from test_timestamp where :TS is not null and col=:TS ", paramsSource,
                    Integer.class);

        }
    }));

}

I found a discution with postgres that explain why: http://www.postgresql-archive.org/quot-could-not-determine-data-type-of-parameter-quot-with-timestamp-td5995489.html

They give a workaround for that (Setting a PGTimestamp instance instead of Timestamp). I was wondering if it is something that could be implemented inside Spring JDBC to increase portability accross multiple databases. It seems there are already some specific code in StatementCreatorUtil related to similar things.

If you think that it is something that makes sense, I can make a pull request


Affects: 5.0.5

Referenced from: pull request #1790

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 12, 2018

Juergen Hoeller commented

Since PGTimestamp is a Postgres-specific class that we'd have to instantiate etc, not just a Postgres-specific convertion for how to use the standard JDBC API, I'm not sure we can easily roll this into StatementCreatorUtils itself.

A pull request highlighting the actual impact of such a change would be useful indeed...

@spring-projects-issues spring-projects-issues added status: waiting-for-triage in: data type: enhancement and removed type: enhancement labels Jan 11, 2019
@snicoll
Copy link
Member

@snicoll snicoll commented Nov 24, 2021

@jhoeller we do have a PR (#1790) but I am not sure it highlights the impact though.

@jhoeller
Copy link
Contributor

@jhoeller jhoeller commented Dec 21, 2021

Locally creating PGTimestamp instances out of given Timestamp or Date values seems like a quite specific workaround. The Postgres JDBC driver could easily do so itself behind the regular JDBC API methods, and that's exactly what I suggest as a proper way out of this. I'm therefore closing this issue on Spring's end.

@jhoeller jhoeller removed the status: waiting-for-triage label Dec 21, 2021
@jhoeller jhoeller self-assigned this Dec 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data
Projects
None yet
Development

No branches or pull requests

3 participants