1) Los nombres de tablas deben estar sí o sí en mayúsculas
2) Los nombres de los campos DEBEN definirse con minúsculas y/o sin tildar el “preserve case” en ApEx (o sin encerrar los nombres de los campos entre comillas)
3) En varias ocasiones me han salido errores extraños del tipo: “duplicate table found: propel” y otros mas extraños aun, tuve que borrar los generated-schema*.yml y volver a construir el esquema y el modelo para que camine.
4) Al generar los forms, los nombres de los widgets se ponen en minusculas, lo que genera problemas al guardarlos despues (porque definimos previamente que sean mayusculas)
5) Ahora estoy peleando con los campos de tipo fecha. Al parecer el Oracle que tengo instalado (XE bajo Windows) maneja las fechas en formato “d/m/Y” o dd/MM/YYYY (o equivalentes), en definitiva: fechas en español) y me salen errores del tipo “Unable to execute INSERT statement. [wrapped: SQLSTATE[HY000]: General error: 1861 OCIStmtExecute: ORA-01861: el literal no coincide con la cadena de formato”, pensaba que tenía que ver con el formato ISO de los validators (Y-m-d, o YYYY/MM/DD o como sea), y aunque cambié el valor de
$this->validatorSchema['FECHA_NAC']->setOption(’date_output’,'d/m/Y’)
al hacer $form->getValues() lo muestra con ese formato, pero Propel insiste en guardar el valor en la base con el formato ISO, lo cual me parece mas que bien.

Paso a contestar la mayoría de puntos ya que creo que los he resuelto en mayor o menor medida:

1. Nombres de tablas

En Oracle los nombres de tablas se normalizan siempre a un formato en mayúsculas. Me parece una opción igual de válida como cualquier otra, aunque a la hora de programar no suele ser recomendable reproducir esto ya que normalmente se reservan las palabras en mayúsculas para nombres de constantes o, en el caso de PHP, superarrays como _REQUEST, _SERVER, etc.

La manera tradicional de nombrar tablas en bases de datos como MySQL, PostreSQL y demás suele ser la de palabras en minúsculas separadas por guión bajo. Una tabla llamada "user_personal_data" debería mapearse a una clase del estilo UserPersonalData en Propel. El problema es que Propel utiliza un método de la clase PhpNameGenerator llamado phpnameMethod que no convierte el nombre a minúsuclas antes de capitalizar la primera letra de cada parte del nombre.

En la versión de Propel en la que pude contribuir recientemente he corregido este comportamiento y he creado un nuevo método de nombrado que abarca más a la hora de normalizar nombres extraños de tablas o columnas. De este modo, no solo obtendrás un esquema de base de datos con un formato tipo UserPersonalData, sino que además podrás tolerar nombres de tabla con carácteres extraños.

Sin embargo, me preocupa el tema de las tildes que no había considerado aun. Creo que tendré que hacer una modificación para que los carácteres "á é í ó ú" se traduzcan en "a e i o u" y no desaparezcan sin más.

Si has descargado Symfony a través de su repositorio de Subversion, debes realizar un "svn up" en la carpeta "symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator" ya que de lo contrario no tendrás la última versión del generador ya que Symfony "bloquea" las librerías de Propel en una versión anterior a mi contribución.

2. Nombres de campos

Esto está resuelto del mismo modo que con el nombre de las tablas del que hablo en el punto anterior.

Yo trabajo contra una base de datos de un ERP Baan IVc4 que utiliza como nombre de columnas cosas como "T$ORNO" o "S$NAMA$RE". Con una versión de Propel actualizada no tendrás ningún problema en generar el schema.yml en semejante escenario. Estos nombres se traducirían como "TOrno" y "SNamaRe".

Sin embargo, el modelo generado a partir del schema.yml anterior no funcionará a no ser que lo edites manualmente ya que en las clases generadas creará incorrectamente el código fuente de las constantes de clase y algún que otro método. En los Peer generará, por ejemplo:

const T$ORNO = "T$ORNO";

Y esto falla.

Yo lo he resuelto realizando modificaciones a otras clases de Propel. Estas modificaciones no las he subido al repositorio de Propel porque creo que exigen un pequeño debate y aprobación por parte del grupo de desarrolladores de Propel ya que son bastante intrusivas y pueden afectar a modelos generados a partir de otros motores de bases de datos.

Básicamente, lo que he hecho es decirle al generador de modelos que emplee para todo el "phpName" y no el "name" de las columnas. Esto soluciona el problema por completo. Puedo enviarle un diff de los cambios que he hecho en estas clases a quien me lo pida para que pueda aplicar los cambios en su instalación de Propel.

3. Duplicate table found: propel

Esto es un error frecuente en Symfony cuando trabajas con varias bases de datos al mismo tiempo. En el fichero databases.yml tendrás una configuración parecida a esta:

all:
db1:
configuración de db1
db2:
configuración de db2
...

(Disculpad la maldita indentación de Worpdress)

El problema es que Symfony no respeta el nombre de la base de datos a la hora de generar el fichero schema.yml y utiliza el nombre "propel" para los esquemas siempre. Lo único que hay que hacer es asegurarse de que la primera posición del fichero schema.yml coincide con db1, db2, etc. antes de generar el modelo y luego todo funcionará de maravilla.

Si os devuelve este error a pesar de haber hecho lo anterior, lo más seguro es que tengáis un problema de cache. En este caso, recomiendo borrar el fichero schema.yml y el directorio lib/model (haz copia de seguridad de esto antes de borrarlo por si las moscas) y empezar de nuevo.

4.Forms

Creo que esto se resuelve con las medidas que he tomado con los nombres de tablas y columnas. En cualquier caso, a mi no me ocurre en mi escenario.

5. Fechas

Lamentablemente, todavía no me he peleado suficiente con esto como para darte una resupesta. Seguramente tú sepas más de esto que yo en este momento. Sólo te puedo recomendar optar siempre que se pueda por Timestamps en la base de datos.

En cualquier caso, hice una corrección en este sentido en el motor de ingeniería inversa que ganantiza que Propel no la cagará (como nos tiene acostumbrados) con los valores por defecto en los campos fecha.

A partir de ahora, si necesitáis trabajar contra Oracle con Propel, podréis realizar tareas de ingeniería inversa para generar el modelo a partir de una base de datos viva con los cambios del changeset 1107 de la versión 1.3 de Propel (http://propel.phpdb.org/trac/changeset/1107).

Huelga decir que supone un gran honor para mi el poder realizar esta aportación y que estoy muy contento por ello.

Si encontráis cualquier problema avisad!

all:

propel:

class: sfPropelDatabase

param:

classname: PropelPDO

phptype: oracle

dsn: oci:dbname=//%IP_DEL_SERVIDOR%:%PUERTO_DEL_SERVIDOR%/%BASE_DE_DATOS%

username: %USUARIO%

password: %CONTRASEÑA%

encoding: utf8

persistent: true

pooling: true

(No consigo que el maldito WordPress indente correctamente el código anterior así que recuerda que la jerarquía es: all >> propel >> param >> resto)

El formato de propel.ini sería el siguiente:

propel.database            = oracle

propel.database.driver     = oracle

propel.database.url        = oci:dbname=//%IP_DEL_SERVIDOR%:%PUERTO_DEL_SERVIDOR%/%BASE_DE_DATOS%

propel.database.creole.url = ${propel.database.url}

propel.database.user       = %USUARIO%

propel.database.password   = %CONTRASEÑA%

propel.database.encoding   = utf8

Lo último que necesitas para que la ingeniería inversa funcione es un parseador de estructura de base de datos para bases de datos de Oracle. Propel 1.3 no trae uno, así que puedes usar el que un servidor ha preparado convenientemente: Oracle Schema Parser (PHP5 script) (Bórrale la extensión "doc" y déjalo en un directorio "lib/plugins/sfPropelPlugin/lib/vendor/propel-generator/classes/propel/engine/database/reverse/oracle" nuevo que tienes que crear en la instalación de Symfony).

Con esto y un bizcocho, ya deberías ser capaz de ejecutar la tarea "propel:build-schema" :)

No hay apenas documentación y para más inri, la poca que hay mezcla versiones incompatibles entre si. Ha sido una auténtica aventura ponerlo en marcha.

La configuración del servidor es la siguiente:

• Ubuntu Server 8.10 x86 sobre VMWare
• PHP5 (la versión del repositorio de Ubuntu)

Parte 1: Instalar el driver OCI (oracle) de PDO

Antes de nada debes saber que vas a tener que instalar la extensión PDO y PDO_OCI a mano. Por un lado, la de PDO_OCI no tiene candidatos y si la compilas a mano, resulta que es incompatible con el API de PDO que te instala el repositorio de ubuntu, por lo que al final, la mejor solución es compilar a mano ambas, a partir del repositorio de fuentes de PEAR.

Para instalar PDO solo hay que hacer un "sudo pecl install pdo". Asegúrate de tener instalado el paquete php-pear y el php5-dev porque si no no podrás hacer esto.

Despues de hacerlo, habrás reemplazado la extensión PDO que te viene al hacer un "apt-get install php5" por el de PEAR.

Ahora viene la parte divertida: instalar en el sistema la extensión PDO_OCI. Para ello debes instalar dos cositas de nuestro gran amigo Oracle (http://www.oracle.com/technology/software/tech/oci/instantclient/index.html):

• Oracle Instant Client (library)
• Oracle Instant Client (SDK)

Lamentablemente, solo podrás utilizar las versiones inferiores a la 11 (de la 10.2.0.4 para abajo).

Luego descomprime la librería en /usr/lib/oracle/10.2.0.4/client/lib y el sdk en /usr/include/oracle/10.2.0.4/client

Luego dile al sistema que añada estas rutas con el comando ldconfig y corriges un par de nombres de ficheros:

sudo ldconfig /usr/lib/oracle/10.2.0.4/client/lib
sudo ldconfig /usr/include/oracle/10.2.0.4/client
sudo ln -s /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so
sudo ln -s /usr/lib/oracle/10.2.0.4/client/lib/libocci.so.10.1 /usr/lib/oracle/10.2.0.4/client/lib/libocci.so

Ahora vamos a descargar las fuentes de PDO_OCI, compilarlas e instalarlas en el sistema:

sudo mkdir /usr/src/pdo_oci
cd /usr/src/pdo_oci
sudo pecl download pdo_oci
sudo tar -zxvf PDO_OCI-1.0.tgz
cd PDO_OCI-1.0
sudo phpize5
sudo ./configure --prefix=/usr --with-pdo-oci=/usr/lib/oracle/10.2.0.4/client
* editar Makefile *
sudo make
sudo make install

Al editar Makefile debéis añadir la ruta a /usr/include/oracle/10.2.0.4/client/include en la directiva "INCLUDES"

Después de esto ya tendréis la extensión instalada en vuestro sistema. Sólo hay que editar /etc/php5/conf.d/pdo.ini y añadir:

extension=pdo_oci.so

Ale, a disfrutar! En el siguiente post explicaré como hacer que todo esto funcione con Propel 1.3 y Symfony, pero antes tengo que averiguar cómo coño se hace T_T.