Обсуждение: BUG #4631: Hibernate Restriction bigint~~bigint

Поиск
Список
Период
Сортировка

BUG #4631: Hibernate Restriction bigint~~bigint

От
"Hauke Runge"
Дата:
The following bug has been logged online:

Bug reference:      4631
Logged by:          Hauke Runge
Email address:      runge@tembit.de
PostgreSQL version: 8.3
Operating system:   XP professional
Description:        Hibernate Restriction bigint~~bigint
Details:

Developing a project with spring, struts, hibernate 3.2 and a postgres 8.1
we were using hibernateCallback like this:

HibernateCallback callback = new HibernateCallback() {
            public Object doInHibernate(Session session) throws
HibernateException, SQLException {
                Criteria ct = session.createCriteria(Reminder.class);

                ct.add(Restrictions.like("user", reminder.getPatient()));
                ct.add(Restrictions.like("suitId", reminder.getSuitId()));

                return ct.list();
            }
        };

this was working very well. Changing to postgreSql 8.3 we got the following
error:
ERROR: operator does not exist: bigint ~~ bigint

we changed the jdbc driver to the latest jdbc3 driver - but the error was
the same.


I think, this could be a bug.

Re: BUG #4631: Hibernate Restriction bigint~~bigint

От
Tom Lane
Дата:
"Hauke Runge" <runge@tembit.de> writes:
> ERROR: operator does not exist: bigint ~~ bigint

> I think, this could be a bug.

Yes: in Hibernate.  They shouldn't be using LIKE on integers.
If it happens that that's intentional and not a symptom of a logic
error on their part, they need to cast the integers to text explicitly.

            regards, tom lane

Re: BUG #4631: Hibernate Restriction bigint~~bigint

От
Guillaume Smet
Дата:
On Tue, Jan 27, 2009 at 4:20 PM, Hauke Runge <runge@tembit.de> wrote:
> this was working very well. Changing to postgreSql 8.3 we got the following
> error:
> ERROR: operator does not exist: bigint ~~ bigint
>
> we changed the jdbc driver to the latest jdbc3 driver - but the error was
> the same.
>
>
> I think, this could be a bug.

You should use Restrictions.eq().

--
Guillaume