Estas en: Home > modelo

Entradas etiquetadas con modelo

Logo Cassandra

Cassandra 2.x y PHP para desarrolladores SQL: El modelo de datos

0

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columns

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

array(
  "nombre" => "email",
  "valor" => "webmaster@localhost.com",
  "timestamp" => time(),
);

Cassandra añade el timestamp automáticamente, con lo que otra forma de representarlo es como un conjunto clave:valor:

nombre_columna:valor

Super columnas (En desuso) y Columnas Compuestas

Las super columnas son un conjunto de columnas con sus correspondientes valores:

array(
  "nombre_superColumna" => array(
    "usuario1" => array(
      "nombre" => "email",
      "valor" => "webmaster@localhost.com",
      "timestamp" => time()
    ),
    "usuario2" => array(
      "nombre" => "email",
      "valor" => "email@email.com",
      "timestamp" => time()
    ),
    "usuario3" => array(
      "nombre" => "email",
      "valor" => "otroemail@otroemail.com",
      "timestamp" => time()
    ),
  ),
)

Las super columnas tienen algunos problemas de rendimiento, sobre todo al ordenarlas. Para solucionarlo se crearon las columnas compuestas que se benefician de los comparadores compuestos, y sobretodo, de CQL 3 (Cassandra Query Language).

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Standard. Si se elige la opción Standard, en la column family solo se podrán guardar columnas, no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

array(
  "name" => "ColumnFamily",
  array( "name" => "SuperColumn",
    array( "colums" )
  ),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
  "name" => "keyspace",
  array("name" => "columnFamily",
    array(
      [...]
    ),
  ),
)
Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: El modelo de datos

5

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columnas

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

array(
  "nombre" => "email",
  "valor" => "webmaster@localhost.com",
  "timestamp" => time(),
);

 

Super columnas

Es el conjunto de columnas con sus correspondientes valores:

array(
  "nombre_superColumna" => array(
    "usuario1" => array(
      "nombre" => "email",
      "valor" => "webmaster@localhost.com",
      "timestamp" => time()
    ),
    "usuario2" => array(
      "nombre" => "email",
      "valor" => "email@email.com",
      "timestamp" => time()
    ),
    "usuario3" => array(
      "nombre" => "email",
      "valor" => "otroemail@otroemail.com",
      "timestamp" => time()
    ),
  ),
)

 

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Standard. Si se elige la opción Standard, en la column family solo se podrán guardar columnas no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

array(
  "name" => "ColumnFamily",
  array( "name" => "SuperColumn",
    array( "colums" )
  ),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
  "name" => "keyspace",
  array("name" => "columnFamily",
    array(
      [...]
    ),
  ),
)
Logo Cassandra

Cassandra y PHP para desarrolladores SQL: El modelo de datos

8

Si has trabajado con una base de datos relacional tal vez te resulte algo confuso al principio comprender el modelo de datos que usa Cassandra, intentaré ser lo más claro posible, pero si te surgen preguntas no dudes en dejarlas en los comentarios.

 

Columnas

El elemento más básico de la base de datos Cassandra es la columna, se compone de tres elementos: nombre de la columna, valor y timestamp. Os muestro un ejemplo como un array:

 array(
“nombre” => “email”,
“valor” => “webmaster@localhost.com”,

“timestamp” => time()

,

)

 

Super columnas

Es el conjunto de columnas con sus correspondientes valores:

array(
“nombre_superColumna” => array(

 

“usuario1” => array(
“nombre” => “email”,
“valor” => “webmaster@localhost.com”,
“timestamp” => time()
),
“usuario2” => array(
“nombre” => “email”,
“valor” => “email@email.com”,
“timestamp” => time()
),

 

“usuario3” => array(
“nombre” => “email”,
“valor” => “otroemail@otroemail.com”,
“timestamp” => time()
),

),

)

 

Familia de columnas

Es el conjunto de columnas o super columnas. Me explico:

Las column Family o  familia de columnas se puede configurar de dos maneras: como Super o como Simple. Si se elige la opción Simple, en la column family solo se podrán guardar columnas no super columnas. En cambio si la column family está configurada como Super podrá guardar, además de las columnas, las super columnas. Esta flexibilidad permite jugar con la base de datos y adaptarla a nuestras necesidades.

Ejemplo:

 array(
“name” => “ColumnFamily”,
array( “name” => “SuperColumn”,
array( “colums” )
),
)

Keyspace

El keyspace es nuestra base de datos, donde alojaremos todas las columFamilies que necesitemos.

Ejemplo:

array(
“name” => “keyspace”,
array(“name” => “columnFamily”,
array(
[…]
),
),
)

Symfony: El modelo (III)

0

CONEXIONES A LA BASE DE DATOS

  1. > php symfony configure:database "mysql://login:password@localhost/blog"
  1. > php symfony --env=prod configure:database "mysql://login:password@localhost/blog"
  1. > php symfony --app=frontend configure:database "mysql://login:password@localhost/blog"

 

  1. > php symfony --name=otraconexion configure:database "mysql://login:password@localhost/blog"

 

Las opciones de conexión con la base de datos también se pueden establecer manualmente en el archivo databases.yml que se encuentra en el directorio config/.

 

  1. all:
  2. propel:
  3. class: sfPropelDatabase
  4. param:
  5. dsn: mysql://login:password@localhost/blog
  1. prod:
  2. propel:
  3. param:
  4. hostspec: mi_servidor_datos
  5. usuarioname: mi_nombre_usuario
  6. password: xxxxxxxxxx
  7.  
  8. all:
  9. propel:
  10. class: sfPropelDatabase
  11. param:
  12. phptype: mysql # fabricante de la base de datos
  13. hostspec: localhost
  14. database: blog
  15. usuarioname: login
  16. password: passwd
  17. port: 80
  18. encoding: utf8 # Codificación utilizada para crear la tabla
  19. persistent: true # Utilizar conexiones persistentes

Los valores permitidos para el parámetro phptype corresponden a los tipos de bases de datos soportados por PDO:

  • mysql
  • mssql
  • pgsql
  • sqlite
  • oracle

Si se utiliza una base de datos de tipo SQLite, el parámetro hostspec debe indicar la ruta al archivo de base de datos.

  1. all:
  2. propel:
  3. class: sfPropelDatabase
  4. param:
  5. phptype: sqlite
  6. database: %SF_DATA_DIR%/blog.db

 

EXTENDER EL MODELO

Los métodos del modelo que se generan automáticamente están muy bien, pero no siempre son suficientes. Si se incluye lógica de negocio propia, es necesario extender el modelo añadiendo nuevos métodos o redefiniendo algunos de los existentes.

 

AÑADIR NUEVOS MÉTODOS

Los nuevos métodos se pueden añadir en las clases vacías del modelo que se generan en el directorio lib/model/. Se emplea $this para invocar a los métodos del objeto actual y self:: para invocar a los métodos estáticos de la clase actual. No se debe olvidar que las clases personalizadas heredan los métodos de las clases Base del directorio lib/model/om/.

  1. <?
  2.  
  3. class Articulo extends BaseArticulo
  4. {
  5. public function __toString()
  6. {
  7. return $this->getTitulo(); // getTitulo() se hereda de BaseArticulo
  8. }
  9. }

También se pueden extender las clases peer, como por ejemplo para obtener todos los artículos ordenados por fecha de creación:

  1. <?
  2.  
  3. class ArticuloPeer extends BaseArticuloPeer
  4. {
  5. public static function getTodosOrdenadosPorFecha()
  6. {
  7. $c = new Criteria();
  8. $c->addAscendingOrderByColumn(self::CREATED_AT);
  9. return self::doSelect($c);
  10. }
  11. }

 

  1. <?
  2.  
  3. foreach (ArticuloPeer::getTodosOrdenadosPorFecha() as $articulo)
  4. {
  5. echo $articulo; // Se llama al método mágico __toString()
  6. }

 

REDEFINIR MÉTODOS EXISTENTES

Si alguno de los métodos generados automáticamente en las clases Base no satisfacen las necesidades de la aplicación, se pueden redefinir en las clases personalizadas. Solamente es necesario mantener el mismo número de argumentos para cada método.

Por ejemplo, el método $articulo->getComentarios() devuelve un array de objetos Comentario, sin ningún tipo de ordenamiento. Si se necesitan los resultados ordenados por fecha de creación siendo el primero el comentario más reciente, se puede redefinir el método getComentarios(). Como el método getComentarios() original (guardado en lib/model/om/BaseArticulo.php) requiere como argumentos un objeto de tipo Criteria y una conexión, la nueva función debe contener esos mismos parámetros.

  1. <?
  2.  
  3. public function getComentarios($criteria = null, $con = null)
  4. {
  5. if (is_null($criteria))
  6. {
  7. $criteria = new Criteria();
  8. }
  9. else
  10. {
  11. // Los objetos se pasan por referencia en PHP5, por lo que se debe clonar
  12. // el objeto original para no modificarlo
  13. $criteria = clone $criteria;
  14. }
  15. $criteria->addDescendingOrderByColumn(ComentarioPeer::CREATED_AT);
  16.  
  17. return parent::getComentarios($criteria, $con);
  18. }

El método personalizado acaba llamando a su método padre en la clase Base, lo que se considera una buena práctica. No obstante, es posible saltarse completamente la clase Base y devolver el resultado directamente.

 

USO DE COMPORTAMIENTOS EN EL MODELO

Algunas de las modificaciones que se realizan en el modelo son genéricas y por tanto se pueden reutilizar. Por ejemplo, los métodos que hacen que un objeto del modelo sea reordenable o un bloqueo de tipo optimistic en la base de datos para evitar conflictos cuando se guardan de forma concurrente los objetos se pueden considerar extensiones genéricas que se pueden añadir a muchas clases.

Symfony encapsula estas extensiones en “comportamientos” (del inglés behaviors). Los comportamientos son clases externas que proporcionan métodos extras a las clases del modelo. Las clases del modelo están definidas de forma que se puedan enganchar estas clases externas y Symfony extiende las clases del modelo mediante sfMixer.

Para habilitar los comportamientos en las clases del modelo, se debe modificar una opción del archivo config/propel.ini:

propel.builder.AddBehaviors = true // El valor por defecto es false

Symfony no incluye por defecto ningún comportamiento, pero se pueden instalar mediante plugins. Una vez que el plugin se ha instalado, se puede asignar un comportamiento a una clase mediante una sola línea de código. Si por ejemplo se ha instalado el plugin sfPropelParanoidBehaviorPlugin en la aplicación, se puede extender la clase Articulo con este comportamiento añadiendo la siguiente línea de código al final del archivo Articulo.class.php:

  1. <?
  2.  
  3. sfPropelBehavior::add('Articulo', array(
  4. 'paranoid' => array('column' => 'deleted_at')
  5. ));

 

Después de volver a generar el modelo, los objetos de tipo Articulo que se borren permanecerán en la base de datos, aunque será invisibles a las consultas que hacen uso de los métodos del ORM, a no ser que se deshabilite temporalmente el comportamiento mediante sfPropelParanoidBehavior::disable().

Desde la versión 1.1 de Symfony también es posible declarar los comportamientos directamente en el archivo schema.yml, incluyéndolos bajo la clave _behaviors.

La lista de plugins de Symfony disponible en el wiki incluye numerosos comportamientos http://trac.symfony-project.org/wiki/SymfonyPlugins#Behaviors. Cada comportamiento tiene su propia documentación y su propia guía de instalación.

 

SINTAXIS EXTENDIDA DEL ESQUEMA

Atributos

Se pueden definir atributos específicos para las conexiones y las tablas. Estas opciones se establecen bajo la clave _attributes.

  1. propel:
  2. _attributes: { noXsd: false, defaultIdMethod: none, package: lib.model }
  3. blog_articulo:
  4. _attributes: { phpName: Articulo }

Si se quiere validar el esquema antes de que se genere el código asociado, se debe desactivar en la conexión el atributo noXSD. La conexión también permite que se le indique el atributo defaultIdMethod. Si no se indica, se utilizará el método nativo de generación de IDs –por ejemplo, autoincrement en MySQL o sequences en PostgreSQL. El otro valor permitido es none.

El atributo package es como un namespace; indica la ruta donde se guardan las clases generadas automáticamente. Su valor por defecto es lib/model/, pero se puede modificar para organizar el modelo en una estructura de subpaquetes. Si por ejemplo no se quieren mezclar en el mismo directorio las clases del núcleo de la aplicación con las clases de un sistema de estadísticas, se pueden definir dos esquemas diferentes con los paquetes lib.model.business y lib.model.stats.

Ya se ha visto el atributo de tabla phpName, que se utiliza para establecer el nombre de la clase generada automáticamente para manejar cada tabla de la base de datos.

Las tablas que guardan contenidos adaptados para diferentes idiomas (es decir, varias versiones del mismo contenido en una tabla relacionada, para conseguir la internacionalización) también pueden definir dos atributos adicionales.

  1. propel:
  2. blog_articulo:
  3. _attributes: { isI18N: true, i18nTable: db_group_i18n }

 

DETALLE DE LAS COLUMNAS

La sintaxis básica ofrece dos posibilidades: dejar que Symfony deduzca las características de una columna a partir de su nombre (indicando un valor vacío para esa columna) o definir el tipo de columna con uno de los tipos predefinidos.

  1. propel:
  2. blog_articulo:
  3. id: # Symfony se encarga de esta columna
  4. titulo: varchar(50) # Definir el tipo explícitamente

Se pueden definir muchos más aspectos de cada columna. Si se definen, se utiliza un array asociativo para indicar las opciones de la columna.

  1. propel:
  2. blog_articulo:
  3. id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
  4. name: { type: varchar(50), default: foobar, index: true }
  5. group_id: { type: integer, foreignTable: db_group, foreignReference: id, onDelete: cascade }

Los parámetros de las columnas son los siguientes:

  • type: Tipo de columna. Se puede elegir entre boolean, tinyint, smallint, integer, bigint, double, float, real, decimal, char, varchar(tamano), longvarchar, date, time, timestamp, bu_date, bu_timestamp, blob y clob
  • required: valor booleano. Si vale true la columna debe tener obligatoriamente un valor.
  • default: el valor por defecto.
  • primaryKey: valor booleano. Si vale true indica que es una clave primaria.
  • autoIncrement: valor booleano. Si se indica true para las columnas de tipo integer, su valor se auto-incrementará.
  • sequence: el nombre de la secuencia para las bases de datos que utilizan secuencias para las columnas autoIncrement (por ejemplo PostgreSQL y Oracle).
  • index: valor booleano. Si vale true, se construye un índice simple; si vale unique se construye un índice único para la columna.
  • foreignTable: el nombre de una tabla, se utiliza para crear una clave externa a otra tabla.
  • foreignReference: el nombre de la columna relacionada si las claves externas se definen mediante foreignTable.
  • onDelete: determina la acción que se ejecuta cuando se borra un registro en una tabla relacionada. Si su valor es setnull, la columna de la clave externa se establece a null. Si su valor es cascade, se borra el registro relacionado. Si el sistema gestor de bases de datos no soporta este comportamiento, el ORM lo emula. Esta opción solo tiene sentido para las columnas que definen una foreignTable y una foreignReference.
  • isCulture: valor booleano. Su valor es true para las columnas de tipo culture en las tablas de contenidos adaptados a otros idiomas.

 

CLAVES EXTERNAS

Además de los atributos de columna foreignTable y foreignReference, es posible añadir claves externas bajo la clave _foreignKeys: de cada tabla.

  1. propel:
  2. blog_articulo:
  3. id:
  4. titulo: varchar(50)
  5. usuario_id: { type: integer }
  6. _foreignKeys:
  7. -
  8. foreignTable: blog_usuario
  9. onDelete: cascade
  10. references:
  11. - { local: usuario_id, foreign: id }

La sintaxis alternativa es muy útil para las claves externas múltiples y para indicar un nombre a cada clave externa.

  1. _foreignKeys:
  2. mi_clave_externa:
  3. foreignTable: db_usuario
  4. onDelete: cascade
  5. references:
  6. - { local: usuario_id, foreign: id }
  7. - { local: post_id, foreign: id }

 

INDICES

Además del atributo de columna index, es posible añadir claves índices bajo la clave _indexes: de cada tabla. Si se quieren crean índices únicos, se debe utilizar la clave _uniques:. En las columnas que requieren un tamaño, por ejemplo por ser columnas de texto, el tamaño del índice se indica entre paréntesis, de la misma forma que se indica el tamaño de cualquier columna.

  1. propel:
  2. blog_articulo:
  3. id:
  4. titulo: varchar(50)
  5. created_at:
  6. _indexes:
  7. mi_indice: [titulo(10), usuario_id]
  8. _uniques:
  9. mi_otro_indice: [created_at]

 

COLUMNAS VACÍAS

Cuando Symfony se encuentra con una columna sin ningún valor, utiliza algo de magia para determinar su valor.

  1. // Las columnas vacías llamadas "id" se consideran claves primarias
  2. id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
  3.  
  4. // Las columnas vacías llamadas "XXX_id" se consideran claves externas
  5. loquesea_id: { type: integer, foreignTable: db_loquesea, foreignReference: id }
  6.  
  7. // Las columnas vacías llamadas created_at, updated at, created_on y updated_on
  8. // se consideran fechas y automáticamente se les asigna el tipo "timestamp"
  9. created_at: { type: timestamp }
  10. updated_at: { type: timestamp }

Para las claves externas, Symfony busca una tabla cuyo phpName sea igual al principio del nombre de la columna; si se encuentra, se utiliza ese nombre de tabla como foreignTable.

 

TABLAS I18N

Symfony permite internacionalizar los contenidos mediante tablas relacionadas. De esta forma, cuando se dispone de contenido que debe ser internacionalizado, se guarda en 2 tablas distintas: una contiene las columnas invariantes y otra las columnas que permiten la internacionalización.

Todo lo anterior se considera de forma implícita cuando en el archivo schema.yml se dispone de una tabla con el nombre cualquiernombre_i18n.

  1. propel:
  2. db_group:
  3. id:
  4. created_at:
  5.  
  6. db_group_i18n:
  7. name: varchar(50)
  1. propel:
  2. db_group:
  3. _attributes: { isI18N: true, i18nTable: db_group_i18n }
  4. id:
  5. created_at:
  6.  
  7. db_group_i18n:
  8. id: { type: integer, required: true, primaryKey: true, foreignTable: db_group, foreignReference: id, onDelete: cascade }
  9. culture: { isCulture: true, type: varchar(7), required: true, primaryKey: true }
  10. name: varchar(50)

 

COMPORTAMIENTOS

Los comportamientos son plugins que modifican el modelo de datos para añadir nuevas funcionalidades a las clases de Propel.

  1. propel:
  2. blog_articulo:
  3. titulo: varchar(50)
  4. _behaviors:
  5. paranoid: { column: deleted_at }

 

Symfony: El modelo (I)

0

Las bases de datos son relacionales. PHP 5 y Symfony están orientados a objetos. Para acceder de forma efectiva a la base de datos desde un contexto orientado a objetos, es necesaria una interfaz que traduzca la lógica de los objetos a la lógica relacional. Esta interfaz se llama ORM (object-relational mapping) o “mapeo de objetos a bases de datos”, y está formada por objetos que permiten acceder a los datos y que contienen en sí mismos el código necesario para hacerlo.

La utilización de objetos en vez de registros y de clases en vez de tablas, tiene otra ventaja: permite añadir métodos accesores en los objetos que no tienen relación directa con una tabla. Si se dispone por ejemplo de una tabla llamada cliente con dos campos llamados nombre y apellidos, puede que se necesite un dato llamado NombreCompleto que incluya y combine el nombre y los apellidos. En el mundo orientado a objetos, es tan fácil como añadir un método accesor a la clase Cliente. Desde el punto de vista de la aplicación, no existen diferencias entre los atributos Nombre, Apellidos, NombreCompleto de la clase Cliente. Solo la propia clase es capaz de determinar si un atributo determinado se corresponde con una columna de la base de datos.

  1. <?php
  2.  
  3. public function getNombreCompleto()
  4. {
  5. return $this->getNombre().' '.$this->getApellidos();
  6. }

Todo el código repetitivo de acceso a los datos y toda la lógica de negocio de los propios datos se puede almacenar en esos objetos. Imagina que se ha definido la clase CarritoCompra en la que se almacenan Productos (que son objetos). Para obtener el precio total del carrito de la compra antes de realizar el pago, se puede crear un método que encapsula el proceso de cálculo:

  1. <?php
  2.  
  3. public function getTotal()
  4. {
  5. $total = 0;
  6. foreach ($this->getProductos() as $producto)
  7. {
  8. $total += $producto->getPrecio() * $producto->getCantidad();
  9. }
  10.  
  11. return $total;
  12. }

 

ESQUEMA DE BASE DE DATOS DE SYMFONY

Para crear el modelo de objetos de datos que utiliza Symfony, se debe traducir el modelo relacional de la base de datos a un modelo de objetos de datos. Para realizar ese mapeo o traducción, el ORM necesita una descripción del modelo relacional, que se llama “esquema” (schema). En el esquema se definen las tablas, sus relaciones y las características de sus columnas.

La sintaxis que utiliza Symfony para definir los esquemas hace uso del formato YAML. Los archivos schema.yml deben guardarse en el directorio miproyecto/config/.

  1. propel:
  2. blog_articulo:
  3. _attributes: { phpName: Articulo }
  4. id:
  5. titulo: varchar(255)
  6. contenido: longvarchar
  7. created_at:
  8. blog_comentario:
  9. _attributes: { phpName: Comentario }
  10. id:
  11. articulo_id:
  12. autor: varchar(255)
  13. contenido: longvarchar
  14. created_at:

 

SINTAXIS BÁSICA DE LOS ESQUEMAS

En el archivo schema.yml, la primera clave representa el nombre de la conexión. Puede contener varias tablas, cada una con varias columnas. Siguiendo la sintaxis de YAML, las claves terminan con dos puntos (:) y la estructura se define mediante la indentación con espacios, no con tabuladores.

Cada tabla puede definir varios atributos, incluyendo el atributo phpName (que es el nombre de la clase PHP que será generada para esa tabla). Si no se menciona el atributo phpName para una tabla, Symfony crea una clase con el mismo nombre que la tabla al que se aplica las normas del camelCase.

Las tablas contienen columnas y el valor de las columnas se puede definir de 3 formas diferentes:

  • Si no se indica nada, Symfony intenta adivinar los atributos más adecuados para la columna en función de su nombre y de una serie de convenciones. Por ejemplo, en el listado anterior no es necesario definir la columna id. Symfony por defecto la trata como de tipo entero (integer), cuyo valor se auto-incrementa y además, clave principal de la tabla. En la tabla blog_comentario, la columna articulo_id se trata como una clave externa a la tabla blog_articulo (las columnas que acaban en _id se consideran claves externas, y su tabla relacionada se determina automáticamente en función de la primera parte del nombre de la columna). Las columnas que se llaman created_at automáticamente se consideran de tipo timestamp. Para este tipo de columnas, no es necesario definir su tipo. Esta es una de las razones por las que es tan fácil crear archivos schema.yml.
  • Si sólo se define un atributo, se considera que es el tipo de columna. Symfony entiende los tipos de columna habituales: boolean, integer, float, date, varchar(tamaño), longvarchar (que se convierte, por ejemplo, en tipo text en MySQL), etc. Para contenidos de texto de más de 256 caracteres, se utiliza el tipo longvarchar, que no tiene tamaño definido (pero que no puede ser mayor que 65KB en MySQL). Los tipos date y timestamp tienen las limitaciones habituales de las fechas de Unix y no pueden almacenar valores anteriores al 1 de Enero de 1970. Como puede ser necesario almacenar fechas anteriores (por ejemplo para las fechas de nacimiento), existe un formato de fechas “anteriores a Unix” que son bu_date and bu_timestamp.
  • Si se necesitan definir otros atributos a la columna (por ejemplo su valor por defecto, si es obligatorio o no, etc.), se indican los atributos como pares clave: valor.

Las columnas también pueden definir el atributo phpName, que es la versión modificada de su nombre según las convenciones habituales (Id, Titulo, Contenido, etc) y que normalmente no es necesario redefinir.

 

LAS CLASES DEL MODELO

Como ya has podido leer, Symfony a través de Propel genera una clase para cada tabla. Para generar esas clases simplemente, una vez hayas terminado de crear el esquema del modelo, en la consola escribe:

> php symfony propel:build-model

Al ejecutar ese comando, se analiza el esquema y se generan las clases base del modelo, que se almacenan en el directorio lib/model/om/ del proyecto:

  • BaseArticulo.php
  • BaseArticuloPeer.php
  • BaseComentario.php
  • BaseComentarioPeer.php

Además, se crean las verdaderas clases del modelo de datos en el directorio lib/model/:

  • Articulo.php
  • ArticuloPeer.php
  • Comentario.php
  • ComentarioPeer.php

Sólo se han definido dos tablas y se han generado ocho archivos. Aunque este hecho no es nada extraño, merece una explicación.

Puede ser necesario añadir métodos y propiedades personalizadas en los objetos del modelo (piensa por ejemplo en el método getNombreCompleto()). También es posible que a medida que el proyecto se esté desarrollando, se añadan tablas o columnas. Además, cada vez que se modifica el archivo schema.yml se deben regenerar las clases del modelo de objetos mediante el comando propel-build-model. Si se añaden los métodos personalizados en las clases que se generan, se borrarían cada vez que se vuelven a generar esas clases.

Las clases con nombre Base del directorio lib/model/om/ son las que se generan directamente a partir del esquema. Nunca se deberían modificar esas clases, porque cada vez que se genera el modelo, se borran todas las clases.

Por otra parte, las clases de objetos propias que están en el directorio lib/model heredan de las clases con nombre Base. Estas clases no se modifican cuando se ejecuta la tarea propel:build-model, por lo que son las clases en las que se añaden los métodos propios.

  1. <?php
  2.  
  3. class Articulo extends BaseArticulo
  4. {
  5. }

Articulo y Comentario son clases objeto que representan un registro de la base de datos. Permiten acceder a las columnas de un registro y a los registros relacionados. Por tanto, es posible obtener el título de un artículo invocando un método del objeto Articulo:

  1. <?php
  2.  
  3. $articulo = new Articulo();
  4.  
  5. // ...
  6. $titulo = $articulo->getTitulo();

ArticuloPeer y ComentarioPeer son clases de tipo “peer“; es decir, clases que tienen métodos estáticos para trabajar con las tablas de la base de datos. Proporcionan los medios necesarios para obtener los registros de las tablas. Sus métodos devuelven normalmente un objeto o una colección de objetos de la clase objeto relacionada:

  1. <?php
  2.  
  3. // $articulos es un array de objetos de la clase Articulo
  4. $articulos = ArticuloPeer::retrieveByPks(array(123, 124, 125));
Ir arriba