Re: ResultSet.getClob() causing problems when used with JPA's @Lob
От | Thomas Kellerer |
---|---|
Тема | Re: ResultSet.getClob() causing problems when used with JPA's @Lob |
Дата | |
Msg-id | nnerrf$rkg$1@ger.gmane.org обсуждение исходный текст |
Ответ на | Re: ResultSet.getClob() causing problems when used with JPA's @Lob (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>) |
Список | pgsql-jdbc |
Vladimir Sitnikov schrieb am 29.07.2016 um 00:20: >>other JDBC implementations. > > I've just looked into PgConnection.createClob, and it turns out the method is not implemented. > This means no one ever used that to pass strings into large objects or whatever thing. I noticed that as well. I wonder if we could use the PgStringClob and PgStringBlob I included with my patch for that purpose? I think the missing methods in those two classes shouldn't be that hard to implement. > Large object API works with bytes, not characters, so I think we can > safely assume that PgPreparedStatement.setClob results into string > datatype (that is it should be just redirected to setString). > > This (plus the patch that enables to getClob for textual results) should solve the problem for the majority of pgjdbc users. > > Thomas is that enough so you can give it a try? Redirecting setClob() to setString() unconditionally would help us in the current migration, yes. I can submit a patch for that, sounds easy enough. > That's really a pity, because the (very unusual) handling of "large objects" makes the Clob/Blob handling quite > incompatiable with other JDBC implementations. > > The problem with Blob remains (I'm not sure if you have one): > postgresql cannot automatically create a large object when it receives "bytea" bind. > > The same "unknown" approach does not work here since "large objects" are stored aside and a colum contains just a "oid"(64bit id). > > That adds yet another case "bytea vs large object" to > https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_features.md#binary-transfer-vs-exact-data-type I still think that having a connection property that switches between large objects and bytea for BLOBs makes sense. Thomas
В списке pgsql-jdbc по дате отправления: