Problema mapeando nombre de columna con 'ñ' (PostgreSQL)

[Rafael Bermúdez Míguez]

Recientemente en una integración compleja encontré un nombre de columna con ñ. Al mapearla con su clase de dominio no la consigo escapar como hago con los espacios en blanco o mayúsculas/minúsculas. Perdido por los foros de hibernate no encontré solución aparente.

 

Hay cantidad de legacy que conocemos operando sobre esas tablas...y otro tanto que desconocemos...cambiar el nombre de la columna no es viable.

 

¿Será por el collation que maneja? El caso es que viene de una migración de access de una migración anterior de advantage....

ENCODING = 'UTF8'
LC_COLLATE = 'Spanish_Spain.1252'
LC_CTYPE = 'Spanish_Spain.1252'

 

 

Tiene que existir una solución sencilla que se me escapa. Al final por no frenar implementé el mapeo a una columna espejo sincronizada bidireccionalmente mediante triggers...

 

 

[Iván López]

Seguro que hay un lugar especial en el infierno para los que crean columnas y tablas con ñ, tildes y demás caracteres especiales ;-)

Has probado a crear una vista que replique todos los campos de la tabla original y cambie el nombre de esa columna problematica ?

Saludos, Iván.

--
Sent from my Nexus 10

--
Has recibido este mensaje porque estás suscrito al grupo "grailsEnCastellano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a grailsencastell...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a grailsenc...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/grailsencastellano.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Rafael Bermúdez Míguez]

Es un quebradero de cabeza....he revisado parte del legacy del que tenemos el código...y accede a las columnas por posición y no por nombre :O

Vistas actualizables, es una asignatura pendiente en postgres, debería mejorar bastante en ese aspecto (si fuese oracle...). De primeras es una solución menos mala que la utilizada, más elegante y clara, menos espagueti, pero quizás podría llevar a un error en la ejecución futura y no se si compensaría todo lo que ofrece.

Pros que le veo:

• Ahorra la sincronización en un sentido
• Me queda más limpio y transparente, ya que no toco la tabla original, y no perturbo el diseño con 2 columnas para idéntico asunto.
• Crear la columna espejo que hice yo puede ser muy costoso en tablas con muchos datos (no era este el caso, que no sobrepasaban los 30.000)
  

Contras:

• El manejo de vistas en postgresql, son de solo lectura (salvo que le cree yo una regla o trigger)
• Mantener esa vista a lo largo del tiempo (si se modifican columnas y añaden restricciones de insercción el día de mañana en la tabla original...podría dar lugar a un fallo inesperado)
  

Gracias por responder Iván, de momento todas las soluciones son bastante forzadas (aunque its works!). Espero que si algún día alguien encuentra "el secreto", lo comparta con nosotros :)

Un saludo