[SOLUCIONADO] Bug (¿?) al intentar trabajar sobre datos obtenidos en una fila de

SIU-Toba Toba - Desarrollo
1

Hola, quería hacer una consulta, al obtener los datos de una fila luego de seleccionarse en el cuadro, utilizo lo siguiente:


<?php
function conf__formulario(toba_ei_formulario $form)
{
	if ($this->dep('localidades')->esta_cargada()) {
		$datos = $this->dep('localidades')->get();
		toba::notificacion()->agregar(dump_array_php($datos));
	}
	$form->set_datos($datos);
}

Esto carga los valores como corresponde en cada campo del formulario para su edición. Hasta ahí, todo bien.
El problema se me presenta cuando quiero operar sobre el array $datos basándome en los datos que acarrea, los datos que representan una string, poseen un caracter extra que me imposibilita hacer comparaciones sobre ellos o bien, buscar dicho valor en otro array de arrays (adjunto una imágen de la salida de la notificación).
http://mensaje.JPG

El array sobre el que deseo hacer la búsqueda es uno que utilizo para cargar valores en un combo (como salida del método get__provincias_argentinas);

 $provincias = array (array('--OTRA--','--OTRA--'),array('BUENOS AIRES','BUENOS AIRES'));

La búsqueda en este array, funciona bien cuando se especifica la constante, pero no cuando utilizo el valor que viene en $datos.


<?php
function conf__formulario(toba_ei_formulario $form)
{
	if ($this->dep('localidades')->esta_cargada()) {
		$datos = $this->dep('localidades')->get();
		$provincias = $this->get__provincias_argentinas();
		//if (!in_array(array('BUENOS AIRES','BUENOS AIRES'), $provincias)) {
		if (!in_array(array($datos['provincia'],$datos['provincia']), $provincias)) {
			//toba::notificacion()->agregar('No lo encontró');
			$datos['provincia_otra'] = $datos['provincia'];
			$datos['provincia']      = '--OTRA--';
		} else {
			//toba::notificacion()->agregar('Lo encontró');
			$datos['provincia_otra'] = $datos[''];
		}
	}
	$form->set_datos($datos);
}

Hay forma de salvar esto?
Probé con Trim($datos[‘provincia’]), pero pareciera no tener efecto. También probé haciendo quote de trim($datos[‘provincia’]).
Tampoco pareciera tener efecto ingresar true como tercer parámetro de la función in_array.
Asimismo, probé varias combinaciones de todo esto.

Desde ya, mil gracias!

2

Si el tipo de dato que estas utilizando en la bd es CHAR(X) en lugar de VARCHAR(X), probablemente te pueda volver con espacios de relleno al final. Sin embargo al hacerle trim esos espacios deberian volar. Por otro lado, $datos[‘provincia’] siempre viene en mayusculas?.. si podes hace lo siguiente y copiame el contenido:


echo "<pre>";
var_dump($datos);
echo "</pre>
<pre>";
var_dump($provincias);
echo "</pre>";

Me gustaria ver si no hay alguna diferencia en los tipos de datos de las componentes del arreglo.
Saludos
Richard

3

Te adjunto el resultado… ahora veo más claro lo que me decís… pero el trim igual me dejó los espacios… es MUY raro.
Igualmente estoy en una etapa totalmente inicial. Todavía no hay nada en producción y si la sugerencia en general para el trabajo PostgreSQL-Toba es utilizar VarChar, lo cambio en 2 minutos (y soluciono por ahí!). Toda la base de datos está definida como Char, pero no por una decisión con conocimiento de causa.

Localidades

array(7) {
  ["abreviatura"]=>
  string(20) "PTA.ALTA            "
  ["cp"]=>
  string(10) "8109      "
  ["id"]=>
  int(6)
  ["id_pais"]=>
  int(1)
  ["nombre"]=>
  string(50) "PUNTA ALTA                                        "
  ["provincia"]=>
  string(50) "BUENOS AIRES                                      "
  ["x_dbr_clave"]=>
  int(0)
}


array(25) {
  [0]=>
  array(2) {
    [0]=>
    string(8) "--OTRA--"
    [1]=>
    string(8) "--OTRA--"
  }
  [1]=>
  array(2) {
    [0]=>
    string(12) "BUENOS AIRES"
    [1]=>
    string(12) "BUENOS AIRES"
  }
  [2]=>
  array(2) {
    [0]=>
    string(15) "CAPITAL FEDERAL"
    [1]=>
    string(15) "CAPITAL FEDERAL"
  }
  [3]=>
  array(2) {
    [0]=>
    string(9) "CATAMARCA"
    [1]=>
    string(9) "CATAMARCA"
  }
  [4]=>
  array(2) {
    [0]=>
    string(7) "CORDOBA"
    [1]=>
    string(7) "CORDOBA"
  }
  [5]=>
  array(2) {
    [0]=>
    string(10) "CORRIENTES"
    [1]=>
    string(10) "CORRIENTES"
  }
  [6]=>
  array(2) {
    [0]=>
    string(5) "CHACO"
    [1]=>
    string(5) "CHACO"
  }
  [7]=>
  array(2) {
    [0]=>
    string(6) "CHUBUT"
    [1]=>
    string(6) "CHUBUT"
  }
  [8]=>
  array(2) {
    [0]=>
    string(10) "ENTRE RIOS"
    [1]=>
    string(10) "ENTRE RIOS"
  }
  [9]=>
  array(2) {
    [0]=>
    string(7) "FORMOSA"
    [1]=>
    string(7) "FORMOSA"
  }
  [10]=>
  array(2) {
    [0]=>
    string(5) "JUJUY"
    [1]=>
    string(5) "JUJUY"
  }
  [11]=>
  array(2) {
    [0]=>
    string(8) "LA PAMPA"
    [1]=>
    string(8) "LA PAMPA"
  }
  [12]=>
  array(2) {
    [0]=>
    string(8) "LA RIOJA"
    [1]=>
    string(8) "LA RIOJA"
  }
  [13]=>
  array(2) {
    [0]=>
    string(7) "MENDOZA"
    [1]=>
    string(7) "MENDOZA"
  }
  [14]=>
  array(2) {
    [0]=>
    string(8) "MISIONES"
    [1]=>
    string(8) "MISIONES"
  }
  [15]=>
  array(2) {
    [0]=>
    string(7) "NEUQUEN"
    [1]=>
    string(7) "NEUQUEN"
  }
  [16]=>
  array(2) {
    [0]=>
    string(9) "RIO NEGRO"
    [1]=>
    string(9) "RIO NEGRO"
  }
  [17]=>
  array(2) {
    [0]=>
    string(5) "SALTA"
    [1]=>
    string(5) "SALTA"
  }
  [18]=>
  array(2) {
    [0]=>
    string(8) "SAN JUAN"
    [1]=>
    string(8) "SAN JUAN"
  }
  [19]=>
  array(2) {
    [0]=>
    string(8) "SAN LUIS"
    [1]=>
    string(8) "SAN LUIS"
  }
  [20]=>
  array(2) {
    [0]=>
    string(8) "SANTA FE"
    [1]=>
    string(8) "SANTA FE"
  }
  [21]=>
  array(2) {
    [0]=>
    string(10) "SANTA CRUZ"
    [1]=>
    string(10) "SANTA CRUZ"
  }
  [22]=>
  array(2) {
    [0]=>
    string(19) "SANTIAGO DEL ESTERO"
    [1]=>
    string(19) "SANTIAGO DEL ESTERO"
  }
  [23]=>
  array(2) {
    [0]=>
    string(16) "TIERRA DEL FUEGO"
    [1]=>
    string(16) "TIERRA DEL FUEGO"
  }
  [24]=>
  array(2) {
    [0]=>
    string(7) "TUCUMAN"
    [1]=>
    string(7) "TUCUMAN"
  }
}
4

Estuve revisando y mirando todo de nuevo.

Efectivamente, si hago el campo VarChar en lugar de Char, el problema se soluciona (probablemente sea el camino. Tenémos que ponernos de acuerdo con los otros desarrolladores).

Si mantengo el tipo de campo como Char, se “solucionó” la duda sobre el trim (lo utilicé de forma distinta). Es una cuestión de semántica, que no resultó obvia para mi… probablemente lo sea para el resto del mundo :frowning:

Esto funciona!:


$datos['provincia'] = trim($datos['provincia']);
if (!in_array(array($datos['provincia'],$datos['provincia']), $provincias)) {
...FUNCIONA CUANDO CORRESPONDE
}

Esto no:


if (!in_array(array(trim($datos['provincia']),trim($datos['provincia'])), $provincias)) {
...NO FUNCIONA NUNCA
}

De cualquier forma, la solución fue encontrada… perdón… y gracias!

5
Todavía no hay nada en producción y si la sugerencia en general para el trabajo PostgreSQL-Toba es utilizar VarChar, lo cambio en 2 minutos (y soluciono por ahí!). Toda la base de datos está definida como Char, pero no por una decisión con conocimiento de causa.

Una explicacion mas profunda sobre porque usar Char o Varchar creo que mereceria la intervencion de Emanuel (el DBA, no el cantante :P).

En realidad probablemente nos habriamos pegado todos con lo mismo, si bien se pueden usar funciones tanto dentro del subindice como en el lado derecho de la asignacion. Aparentemente no le gusta mucho en el constructor, supongo que este seria el momento para que un profesor de Lenguajes de Programacion nos dijera: ‘Te lo dije!..’ :P.

Me alegro que lo hayas podido solucionar, no pidas perdon… estamos para ayudarte.
Saludos
Richard

6

Por el tema del Char o Varchar, estuve averiguando.

Son similares, aunque el Char tendría la contra de que ocuparía más lugar, y el pro de que cualquier búsqueda o recuperación sería más rápida.
En uno o en otro caso, no habría un dato mensurable de comparación que volcara definitivamente la balanza para uno u otro lado.
Lo óptimo sería utilizar el Char para datos de no más de, digamos, 10 caracteres, y aquellos datos que sepamos tendrán mucho ajetreo; y Varchar en cualquier otro caso.

Desde este punto de vista, dada la cantidad de datos que manipulará el sistema que estoy desarrollando, no es un dato preocupante el hecho de elegir uno u otro, y por una “limpieza” de código hemos optado por Varchar para todo campo de caracter.

Por otro lado, PostgreSQL “asegura” que en el caso de Char, retorna directamente el valor “trimeado”, si espacios excedentes a la derecha, por lo que supongo que es la Api de Toba la que está “creando” las string(50) con el resto de los caracteres (vease el dump más arriba).
Me pareció piola llamar la atención sobre este detalle que puede, o no, ser importante.

Gracias nuevamente,

7

Hola Martín,
Es un tema del driver de PHP de postgres (pdo_pgsql), no hace el trim, tenés que hacerlo manualmente. Es una de las razones por las que no usamos CHAR(X)

8

Impecableeeee!!! más que respondido y solucionado.
Nuevamente…

MIL GRACIAS