Hola, la consulta puntual es como utilizar en forma correcta el parseo de errores.
De momento estoy utilizando el siguiente esquema de control de errores:
<?php...
try{
$this->dep('domicilios_tipos')->sincronizar();
$this->resetear();
}catch (toba_error_db $error) {
$sql_state = $error->get_sqlstate();
if ($sql_state == 'db_23505') {
throw new toba_error_usuario('Ya existe un tipo de domicilio con ese nombre.');
} else {
throw $error;
}
}
Esto funciona correctamente, sin mayores problemas.
Con la idea de unificar criterios en el informe de errores, probé utilizando los mensajes definidos en la configuración del proyecto, y no tuve problemas.
El código, simplemente fue el mismo, sin el control de excepciones del try/catch, y cuando el error sucedió, se mostró el error previamente definido.
lo que no pude luego de varios intentos y buscar dentro de la documentación, fue figurarme como hacer para obtener los datos parseados para poder mostrar el mensaje personalizado.
3.1) en el contexto_ejecucion definí
<?php...
function conf__inicial()
{
toba::db()->set_parser_errores(new toba_parser_error_db_postgres7());
}
3.2) en la fuente de datos tildé la opción del parseo de errores.
3.3) ¿???
Si es posible, me gustaría me indiquen, sobre el ejemplo que cito en el punto 1, cual sería la correcta forma de mostrar el error a través de este método?
MIL GRACIAS!!!
Hola, una consulta a ver si entiendo bien. Vos estas preguntando concretamente cuál de los tres métodos utilizar? o como personalizar el primer método?
Si es la primer pregunta, creo que lo mejor es utilizar el parse de errores definido en el núcleo. Definiendolo en el contexto de ejecución debería salir con fritas. Luego si existe algún error de sql (por ejemplo llamando a toba:db()->consular()), el mismo es atrapado y parseado automáticamente por el núcleo de toba, visualizando un mensaje mucho más amigable.
Exacto, la idea sería utilizar el método que yo denomino como 3, el que se setea en la Fuente de Datos al tildar parseo de errores. El tema es que mirando la documentación, no entendí para nada como hacerlo.
Hice algunos pasos, pero no pude hacerlo funcionar.
Ah joya. Para que funcione el tercer caso tenés que extender la fuente de datos. Para ello te vas a…
Configuración de toba (llave inglesa)
Configuración general > Propiedades
Solapa extensión del núcleo
Contexto de ejecución
Allí le definis una clase que debe contener al menos dos métodos
function conf__inicial()
{
//-- Manejo de errores en la base de datos
toba::db()->set_parser_errores(new toba_parser_error_db_postgres7());
}
function conf__final(){}
Y voila… (si es que todo anda como espero jeje).
Saludos.
P.D.: ésta clase debe heredar de toba_interface_contexto_ejecucion
como capturo los errores?
2.1) como un código similar a la opción 1? pero con que API? que valores me devuelve?
2.2) o con un código similar a la opción 2?.. y donde lo parseo en este caso?
No es necesario capturar los errores ya que lo hace el núcleo de toba y muestra un mensaje acorde a lo sucedido. Por ejemplo si intentas eliminar un registro que es referenciado desde otro (FK), toba dirá algo como “no es posible eliminar el registro de la tabla X porque está siendo referenciado por la tabla Y”.
Vuelvo sobre el tema, hice lo que me indicaste, dejé el código como el que sigue:
<?php...
function evt__formulario__eliminar()
{
$this->dep('domicilios_tipos')->eliminar_todo();
$this->resetear();
}
...
Forcé el error intentando eliminar un registro que se referencia en otra tabla…, y me tira lo que adjunto. Ese es el mensaje que el parseo de Toba debe tirarme? se me ocurre que no, debe ser más amigable… y yo debo estar errándole en algo.
Quizá me están faltando comentarios en los campos de las tablas en postgre? o algo así?
Exacto, el parseo de errores trabaja con los comentarios de campos en la definición de la tabla. De todas maneras el link “más info” solo se habilita en el caso de que el modo “debug” del proyecto este habilitado. Lo cuál podés habilitar o no dependiendo de tus necesidades. En el caso de habilitarlo y agregarle comentarios a los campos en la tabla, podrías mostrar un mensaje un poco más ameno. Por ejemplo “update o delete en Tipos de Domicilio viola la llave foranea Tipo de Domicilio en la tabla Domicilio de Docentes”.
Casi… pero no pude hacerlo…
Comentarie los campos en la base de datos (en el postgresql), pero sigue apareciendo el mismo error que te mostré antes.
También puse comentarios en la constrain (fk), en la tabla docentes_domicilios, desde la cual, se referencia a la otra tabla… mismo mensaje.
El resto ya estaba hecho.
Solo no pude encontrar el tilde para el debug, como para probar sin tildarlo… el único Debug que encontré es el del log… es ese? habría que poner Error en el log?
Algo me esta faltando!
Podrías adjuntarme una pantalla de la solapa extensión del núcleo?. De paso también esaría bueno adjuntar el archivo que subclasea al contexto de ejecución.
No tengo el proyecto a la mano. Pero mientras tanto, asi te paso toda la mayor información posible.
En PostgreSQL, donde es que tengo que comentariar el error.
En la constrain definida en la tabla padre (docentes_domicilios, que tiene una constrain fk sobre el campo id_tipo_domicilio)? y eventualmente sobre la contrain unique en la tabla tipos_domicilios (para chequear la duplicidad de datos)?
Es decir, se me ocurre que es siempre sobre las constrain, o no? el comentario común… que figura al editar los campos, tablas, índices, constrain, etc?
Con esta información confirmada, hago las últimas pruebas y si no logro hacerlo funcionar, te paso incluso como tengo definidas las tablas… se me ocurre que es un tilde en algún lado… pero… hasta no verlo, estoy complicado!!
Yo me refería a que cada campo en particular debe estar comentariado. Te paso una captura de donde encontrar esa opción con pgAdmin y un enlace a como hacerlo mediante comandos sql.
Te adjunto los códigos involucrados, y en las fotos de la definición del contexto de ejecución, abm en el cual intento eliminar un tipo de domicilio que ya está en uso (PARTICULAR), y las definiciones de las tablas. Solo agregué comentarios en los campos id_domicilio_tipo en docentes_domicilios y en los campos id y nombre de la tabla domicilios_tipos… igual, no entiendo como termina de funcionar… es decir, como se armará la frase a partir de lo que yo ponga en los comentarios.
Esta pareciera ser la mejor solución genérica, pero la verdad, no termino de encontrarle la vuelta.
Formulario
<?php
...
function evt__formulario__eliminar()
{
$this->dep('domicilios_tipos')->eliminar_todo();
$this->resetear();
}
...
?>
Contexto de ejecución
<?php
class contexto_ejecucion implements toba_interface_contexto_ejecucion
{
function conf__inicial()
{
toba::db()->set_parser_errores(new toba_parser_error_db_postgres7());
}
function conf__final()
{
}
}
?>
no se si ya pasaste por aca pero te dejo un link a la documentación de la parte de parseo de errores, creo que puede darte una idea mas acabada de como funciona el esquema.
Hola Richard…
El enlace no me anduvo.
Pero si, creo, en realidad lo que corresponde hacer en el editor y en código PHP creo está todo hecho.
Me faltaba quizá definir bien los comentarios en los campos de postgresql, pero eso “estaría” bien hecho. Sin embargo siguo sin lograr que funcione… creo haber seguido todos los pasos que me indicó Rodrigo, pero sigue sin parecerme una solución viable… pese a que a grandes rasgos sería la mejor solución.
Dado que no pudiste acceder a la pagina te copio parte del contenido de la misma que creo te puede ser util:
* Definir un método para cada sql_state que se quiera capturar. Estos metodos deberan devolver el mensaje parseado para ser mostrado al cliente. Ej de definición:
function parsear_sqlstate_23503($accion, $sql, $mensaje)
Adicionalmente se pueden definir metodos auxiliares a este:
* Definir un método que armara el mensaje en cuestión uniendo todos los trozos.
* Definir un método que recupere los datos de los comentarios para los objetos involucrados.
Es importante notar que el manejador de errores usa una conexión alternativa a la base de datos y no la conexión principal sobre la que opera el sistema.
El parseo de los mensajes de error se puede activar de dos maneras distintas a partir de Toba 1.4.0:
* Haciendo uso del check Parsea Errores dentro del Editor de fuentes de datos
* Activándolo manualmente desde una subclase definida para la fuente de datos en cuestión:
<?php
class toba_referencia_fuente_datos extends toba_fuente_datos
{
/**
* Antes de conectarse a la base de datos, le digo que la misma posee esquema de auditoría
* De esta forma se creará automáticamente la tabla temporal y se asignará el usuario.
*/
function pre_conectar()
{
$this->set_fuente_parsea_errores(true);
}
}
?>
Si, en su momento lo leí. Ahora no pude acceder, pero es un problema del lugar desde el que accedo.
Siguiendo los pasos que me indica la página y los tips que me fue dando Rodrigo, lo único que me quedaría es armar los errores según:
function parsear_sqlstate_23503($accion, $sql, $mensaje)
Ahora bien… esta función, la defino extendiendo la fuente de datos, o bien, donde extendí el contexto de ejecución?
Nop… esa funcion la definis extendiendo el parser de errores… osea… te harias tu propio parser de errores para postgres. Luego en runtime le seteas como manejador de errores el objeto de esta nueva clase y listo.