2010-09-17 4 views
10

Próbuję edytować tabelę w PostgreSQL przy użyciu JPA w Glassfish przy użyciu EclipseLink. Kiedy wstawiam encję, działa dobrze. Ale gdy próbuję edytować lub usunąć ten sam obiekt, kończy się niepowodzeniem z następującym błędem. Dowolny pomysł?Żaden operator nie pasuje do podanej nazwy i typu argumentu. Może być konieczne dodanie rzutowania typów jawnych. - Netbeans, Postgresql 8.4 i Glassfish

 
Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.DatabaseException 
Internal Exception: org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying 
    Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts. 
    Position: 38 
Error Code: 0 
     at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:333) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1422) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:799) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:867) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:587) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:530) 
     at org.eclipse.persistence.internal.sessions.AbstractSession.executeCall(AbstractSession.java:914) 
     at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:205) 
     at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:191) 
     at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.deleteObject(DatasourceCallQueryMechanism.java:182) 
     at org.eclipse.persistence.internal.queries.StatementQueryMechanism.deleteObject(StatementQueryMechanism.java:101) 
     at org.eclipse.persistence.queries.DeleteObjectQuery.executeDatabaseQuery(DeleteObjectQuery.java:167) 
     at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:675) 
     at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:589) 
     at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:109) 
     at org.eclipse.persistence.queries.DeleteObjectQuery.executeInUnitOfWorkObjectLevelModifyQuery(DeleteObjectQuery.java:112) 
     at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:86) 
     at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2857) 
     at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1225) 
     at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1207) 
     at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1167) 
     at org.eclipse.persistence.internal.sessions.CommitManager.deleteAllObjects(CommitManager.java:297) 
     at org.eclipse.persistence.internal.sessions.CommitManager.deleteAllObjects(CommitManager.java:256) 
     at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1406) 
     at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:547) 
     at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1508) 
     at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3128) 
     at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:268) 
     at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:157) 
     at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68) 
     at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:412) 
     ... 25 more 
Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying 
    Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts. 
    Position: 38 
     at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) 
     at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) 
     at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) 
     at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) 
     at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367) 
     at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:321) 
     at com.sun.gjc.spi.base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:108) 
     at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:792) 
     ... 53 more 
Java Result: 1 
+0

Proszę pokazać swój podmiot, w odpowiedniej tabeli, może swój kod w razie potrzeby, a wygenerowany SQL. Zobacz [to poprzednie pytanie] (http://stackoverflow.com/questions/2374395/is-it-possible-to-output-generated-sql-using-eclipselink- without-having-to-increa), aby wyprowadzić wygenerowany SQL . –

+0

Aby nie zhakować Cię ORM i postgres oprogramowania zewnętrznego, możesz zarejestrować swoje własne odlewy i porównać operacje. [Proszę spojrzeć na przykład w podobnym pytaniu] (http://stackoverflow.com/questions/20773805/postgresql-enum-and-character-varying-updating/43748427#43748427). P.S. To była odpowiedź, ale usunięta z jakiegoś powodu ... – Hubbitus

Odpowiedz

8

To główny błąd:

ERROR: operator does not exist: integer = character varying

kod stara się dopasować liczbę całkowitą i ciąg, to nie zadziała. Napraw swój kod, uzyskaj zapytanie, które jest zaangażowane, aby sprawdzić, czy to naprawiłeś. Zobacz także pliki dziennika PostgreSQL.

Obejście problemu (NIE ROZWIĄZANIE!) Polega na wykonaniu odlewu. Check this article.

+0

czy znalazłeś to, co to rzuciło? – RMcNairn

11

Miałem ten problem i rozwiązany. Było to spowodowane klauzulą ​​WHERE zawierającą wartość String zamiast liczby całkowitej.

0

Bracie, miałem ten sam problem. Chodzi o to, że zbudowałem konstruktora zapytań, dość złożonego, który budował swoje predykaty dynamicznie oczekując na parametry, które zostały ustawione i buforował zapytania. W każdym razie, zanim zbudowałem mój program do generowania zapytań, miałem kod obiektowy zorientowany na obiekt, który zbudował to samo (z wyjątkiem oczywiście, że nie buforował zapytań i nie używał parametrów), który działał bezbłędnie. Teraz, gdy mój konstruktor próbował zrobić to samo, mój PostgreSQL wyrzucił ten pieprzony błąd, który również otrzymałeś. Sprawdziłem wygenerowany kod SQL i nie znalazłem błędów. Dziwne naprawdę.

Moje wyszukiwanie wkrótce wykazało, że był to jeden konkretny predykat w klauzuli WHERE, która spowodowała ten błąd. Jednak ten predykat został zbudowany za pomocą kodu, który wyglądał, prawie jak, dokładnie tak, jak wyglądał kod proceduralny, zanim ten wyjątek zaczął pojawiać się znikąd.

Ale widziałem jedną rzecz, którą zrobiłem inaczej w moim konstruktorze, w przeciwieństwie do tego, co wcześniej zrobił kod proceduralny. Był to jeden z predykatów, które umieścił w klauzuli WHERE! Zacząłem więc przesuwać ten predykat i wkrótce odkryłem, że rzeczywiście kolejność predykatów miała wiele do powiedzenia. Gdybym miał ten predykat sam, moje zapytanie zadziałało (ale zwróciło błędne dopasowanie wyników oczywiście), jeśli umieściłbym go z jednym lub drugim orzecznikiem, który czasem działał, nie działało innym razem. Co więcej, naśladowanie poprzedniej kolejności kodu proceduralnego też nie działało. To, co w końcu zadziałało, polegało na umieszczeniu tego demonicznego predykatu na początku mojej klauzuli WHERE, ponieważ dodano pierwszy predykat! Więc znowu, jeśli nie wyraziłem się jasno, kolejność, w jakiej moje predykaty zostały dodane do metody/klauzuli WHERE, tworzyły ten wyjątek.

0

Myślę, że może to wynikać z wielu rzeczy. W moim przypadku miał warunek "WHERE IN IN" w moim zapytaniu i ustawiałem identyfikatory oddzielone myślnikiem jako ciąg znaków przy użyciu metody setString na PreparedStatement.

Nie jestem pewien, czy jest lepszy sposób, aby to zrobić, ale po prostu dodałem symbol zastępczy w moim oświadczeniu i zastąpiłem go własnymi wartościami.

0

Jeśli ktoś jest o ten wyjątek i buduje zapytania przy użyciu Scala ciągi wielo-line:

Wygląda na to, że jest problem z niektórymi sterownikami WZP w tej sytuacji. Nie jestem pewien, jaki jest charakter, który Scala używa dla LINII KOŃCA, ale gdy masz parametr bezpośrednio na końcu linii, znak LINIA END wydaje się być dołączony do parametru, więc kiedy sterownik analizuje zapytanie, pojawia się błąd.Prosta praca wokół jest pozostawienie pustego miejsca tuż po param na koniec:

SELECT * FROM some_table a 
WHERE a.col = ?param 
AND a.col2 = ?param2 

Tak, tylko upewnij się, aby zostawić puste miejsce po param (i param2, jeśli istnieje podział wiersza).

0

Jeśli używasz Primefaces, powinieneś wstawić do pliku .xhtml, aby konwertował poprawnie na liczbę całkowitą java. Na przykład:

<p:selectCheckboxMenu 
    id="frameSelect" 
    widgetVar="frameSelectBox" 
    filter="true" 
    filterMatchMode="contains" 
    label="#{messages['frame']}" 
    value="#{platform.frameBean.selectedFramesTypesList}" 
    converter="javax.faces.Integer"> 
    <f:selectItems 
     value="#{platform.frameBean.framesTypesList}" 
     var="area" 
     itemLabel="#{area}" 
     itemValue="#{area}" /> 
</p:selectCheckboxMenu> 
1

Nie wygląda jak masz odpowiedź, ale problem ten może również pełzanie jeśli jesteś przejazdem zerowych identyfikatorów do swojego JPA Predicate.

Na przykład.

Jeśli zrobiłem zapytanie na temat kotów, aby uzyskać listę. Który zwraca 3 wyniki.

Lista catList;

Przejmuję następnie listę kotów i przechowuję klucz foriegna kota, który może leashTypeId na innej liście.

List<Integer> leashTypeIds= new ArrayList<>(); 

for(Cats c : catList){ 
    leashTypeIds.add(c.getLeashTypeId); 
} 

jpaController().findLeashes(leashTypeIds); 

Jeżeli którykolwiek z kotami w Catlist mieć wartość null leashTypeId będzie rzucać ten błąd przy próbie zapytanie do DB.

(Wystarczy sobie sprawę, że jestem delegowania na 5-letnią wątek, może ktoś znajdzie to przydatne)

Powiązane problemy