On 01/29/2014 12:07 AM, Craig Ringer wrote:
> On 01/29/2014 02:36 PM, David Johnston wrote:
>>
>> The "correct" solution would seem to be for ORMs to "bind unknown" against
>> the input but only when the supplied string is meant to be a representation
>> of a PostgreSQL type as opposed to being actual string data. The ORM is free
>> to provide the necessary API to distinguish between the two and the caller
>> has to know then database to call the proper method (i.e., not setString if
>> your data intended for anything besides a text/varchar column).
>
> I certainly agree that that's the ideal, and it's closer to achievable
> than any other fix to these sorts of systems.
>
> A challenge I've found when approaching this from the ORM side has been
> getting people to care. The sentiment has tended to be along the lines
> of: No other DBMS does this or requires this, why do we have to jump
> through hoops just to make PostgreSQL happy?
>
> I'm not claiming that's a good reason for inaction.
>
> I think there's more hope of getting ORM systems to differentiate
> between "unknown-typed literal" and "concrete text-typed literal" than
> actually implementing proper support for Pg's numerous useful types. Not
> much more hope, but some.
>
> Look at the example that started this thread, though. The stack is:
>
> PostgreSQL
> PgJDBC
> Java JDBC API
> EBean ORM
> Play! Framework
>
> and *every level* needs to have a clue about this or a way to pass the
> information trough transparently.
And therein lies the problem, in the pursuit of simplicity, application
developers have embraced complicated stacks. A change at any point in
the above stack has the potential to unravel the whole system. So it is
not obvious to me that 'fixing' one end of the stack is going to solve
the problem as a whole.
>
> Now think about Hibernate, Sequel ORM, Django ORM, ActiveRecord,
> EclipseLink, OpenJPA, DataMapper, Entity Framework, EBean, TopLink,
> iBatis/MyBatis, Doctrine, Propel, CakePHP, Zend, SQLAlchemy, ....
>
> Wouldn't it be nice if we could find a solution to this user pain point
> in one place?
See above, I do not think that is possible.
>
--
Adrian Klaver
adrian.klaver@gmail.com