Re: ResultSet.getClob() causing problems when used with JPA's @Lob
| От | Vladimir Sitnikov |
|---|---|
| Тема | Re: ResultSet.getClob() causing problems when used with JPA's @Lob |
| Дата | |
| Msg-id | CAB=Je-EWdfRaS4X3x=txQtLKRm2rOy1xE91t=4v2cD4KtNpdmQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: ResultSet.getClob() causing problems when used with JPA's @Lob (Thomas Kellerer <spam_eater@gmx.net>) |
| Ответы |
Re: ResultSet.getClob() causing problems when used with JPA's @Lob
|
| Список | pgsql-jdbc |
>It would be nice if someone else could point me in the right direction, because I think
that only a change to PreparedStatement would make that complete.
that only a change to PreparedStatement would make that complete.
Am I right your problem is "find a way to identify database type at PreparedStatement#setClob time"?
I'm afraid, there's no solution for that.
Technically speaking, java types are used to parse the SQL properly.
Suppose there's a function process(int4) and function process(text). When using prepareStatement("process(?)") at java side you can refer to both of those and the exact overload depends on the setXXX method.
For instance, if you call setString, then process(text) variation will be called.
Well, let's revert to our clob/text stuff.
I'm not quite sure we can easily figure out what is the proper data type for the bind.
I do not like the idea "having additional round trip to the database just to resolve desired bind types".
I do not like the idea of having a switch that binds setClob to text or lob database types either.
Vladimir
В списке pgsql-jdbc по дате отправления: