Arndt's Blog

Spooky Exceptions (3) – Internal Exception: org.postgresql.util.PSQLException: Der in SQL für eine Instanz von …. zu verwendende Datentyp kann nicht abgeleitet werden. Benutzen Sie ’setObject()‘ mit einem expliziten Typ, um ihn festzulegen.

Die Anwendung, bei deren Entwicklung die Exception aufgetreten ist, basiert auf

  • Java 8
  • Wildfly 10.x
  • Eclipselink
  • Postgres 9.x

Situation

Folgende Exception wurde bei einer JPA Suchanfrage geworfen

09:54:31,868 INFO  [stdout] (default task-55) [EL Warning]: 2016-02-26 09:54:31.868--UnitOfWork(1660853426)--
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DatabaseException
09:54:31,868 INFO  [stdout] (default task-55) Internal Exception: org.postgresql.util.PSQLException: 
Der in SQL für eine Instanz von de.schoeso.desy.ejb.entity.hr.AccountingPeriod zu verwendende Datentyp kann nicht abgeleitet werden. Benutzen Sie 'setObject()' mit einem expliziten Typ, um ihn festzulegen.
09:54:31,868 INFO  [stdout] (default task-55) Error Code: 0
09:54:31,868 INFO  [stdout] (default task-55) Call: SELECT t3.amount, t3.description, t3.wage_type_type_id, ...

...

09:54:31,872 ERROR [org.jboss.as.ejb3.invocation] (default task-55) WFLYEJB0034: EJB Invocation failed on component 
AccountingManualWageTypeDataFacade for method 
public java.util.List de.schoeso.desy.ejb.facade.hr.AccountingManualWageTypeDataFacade.findByVariousParameters(
de.schoeso.desy.ejb.entity.hr.employee.Employee,de.schoeso.project.ejb31.entity.org.unit.UnitOfOrganisation,
de.schoeso.desy.ejb.entity.hr.AccountingPeriod): javax.ejb.EJBException: javax.persistence.PersistenceException: 
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.6.2.v20151217-774c696): 
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: Der in SQL für eine Instanz von de.schoeso.desy.ejb.entity.hr.AccountingPeriod 
zu verwendende Datentyp kann nicht abgeleitet werden. Benutzen Sie 'setObject()' mit einem expliziten Typ, um ihn festzulegen.
Error Code: 0
Call: SELECT t3.amount, t3.description ...

Lösung

In diesem Beispiel wurde eine JPA Query für eine Klasse erstellt, die auf ein anderes Objekt (AccountingPeriod) verweist. In den Join Columns war eines von zwei Attributen, falsch geschrieben und mit , insertable = false, updatable = false gekennzeichnet. Nach Korrektur des Schreibfehlers lief die Abfrage fehlerfrei.

2te Situation – 2025

Eine ähnliche Exception trat nochmals auf

Exception in thread „AWT-EventQueue-0“ jakarta.ejb.EJBException: jakarta.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services – 4.0.2.v202306130914): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: Der in SQL für eine Instanz von de.ecr.bean.org.nation.entity.Nation zu verwendende Datentyp kann nicht abgeleitet werden. Benutzen Sie ’setObject()‘ mit einem expliziten Typ, um ihn festzulegen.
Error Code: 0
Call: SELECT t3.id, t3.billing_category_type, t3.centralized_billing, t3.collective_confirm_active, t3.collective_confirm_period_type, t3.commercial_register, t3.company_domicile, t3.company_name_delivery, t3.company_name_invoice, t3.form_of_organisation, t3.general_manager, t3.inactive, t3.information, t3.inventory_request, t3.margensystem, t3.name, t3.payment_target_days, t3.process_block, t3.process_one_timer, t3.service_partner, t3.logo_type, t3.service_provider_number, t3.shipping_address_exists, t3.short_name, t3.tax_number, t3.timeLastChange, t3.time_request_exceeded, t3.vat_number FROM sp_service_provider t3 LEFT OUTER JOIN sp_service_provider t0 ON (t3.id = t0.id) LEFT OUTER JOIN ADDRESS t1 ON (t1.id = t0.shipping_address_id) LEFT OUTER JOIN ADDRESS t2 ON (t2.id = t0.billing_address_id), org_nation t5, org_nation t4 WHERE ((LOWER(t3.service_provider_number) LIKE ? AND (CASE WHEN t3.shipping_address_exists THEN ELSE END = ?)) AND ((t4.nation_id = t1.land) AND (t5.nation_id = t2.land)))
bind => [2 parameters bound]

Lösung

In der Meldung ist zu sehen, dass das „CASE WHEN“ etwas merkwürdig aussieht. Ursache war hier, dass im „CASE WHEN“ mit Objekten als Ergebnis gearbeitet wurde. Dies scheint aktuell nicht zu funktionieren. Als auf den primitiven Typ der „id“ in dem Objekt gewechselt wurde (String), konnte die Abfrage verarbeitet werden.

Du hast Fragen oder Anmerkungen? Kontakt: arndt@schoenb.de

arndt

,