{"id":139,"date":"2017-05-04T18:05:08","date_gmt":"2017-05-04T23:05:08","guid":{"rendered":"https:\/\/drmad.org\/blog\/?p=139"},"modified":"2021-06-20T22:52:29","modified_gmt":"2021-06-21T03:52:29","slug":"nuevo-orm-para-vendimia","status":"publish","type":"post","link":"https:\/\/drmad.org\/blog\/nuevo-orm-para-vendimia.html","title":{"rendered":"Nuevo ORM para Vendimia"},"content":{"rendered":"\n

No he tenido tiempo de escribir sobre mi framework de desarrollo web Vendimia<\/a>. Y ahora he tenido una idea para mejorar su ORM. Por algo a\u00fan est\u00e1 versi\u00f3n alpha <\/i>\ud83d\ude00 As\u00ed que let’s rubber ducking!<\/i>.<\/p>\n\n\n\n\n\n\n\n

El presente<\/h2>\n\n\n\n

Actualmente Vendimia<\/a> tiene un ORM similar a Rails<\/a>: una clase inicialmente vac\u00eda que extiende a Vendimia\\ActiveRecord\\Record<\/code>, y las relaciones se definen creando variables est\u00e1ticas $belongs_to<\/code>, $has_one<\/code>, y $has_many<\/code> dentro de la clase modelo. En su primera versi\u00f3n le hab\u00eda creado varios m\u00e9todos m\u00e1gicos tipo Django<\/a> como:<\/p>\n\n\n\n

\n
\n
\n
namespace products;\n\n$products = models\\product::find_where_name_contains(\"keyboard\");<\/pre>\n\n\n\n
<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
Lo que genera un SELECT `products_product`.* FROM `products_product` WHERE (`name` LIKE \"%keyboard%\");<\/code>, y devuelve un objeto Vendimia\\ActiveRecord\\RecordSet<\/code> con cada registro del resultado.<\/p>\n\n\n\n
En la segunda iteraci\u00f3n del ORM no le implement\u00e9 dichos m\u00e9todos m\u00e1gicos, en parte por flojera, y en parte porque no son buenas pr\u00e1cticas de programaci\u00f3n <\/em>(los IDE no los identifican, pueden causar confusi\u00f3n, etc.). Tengo pensado crear un trait<\/code> para selectivamente a\u00f1adir a un modelo los m\u00e9todos m\u00e1gicos.<\/p>\n\n\n\n
Actualmente no realiza validaci\u00f3n de los valores de los campos. Vendimia no conoce los campos de la tabla (a pesar que si los conoce, lee m\u00e1s adelante), ni su tipo. Si a\u00f1ades una propiedad de la clase cuyo campo no existe en la db, ser\u00e1 el SQL quien genere una excepci\u00f3n.<\/p>\n\n\n\n
A mi no me molesta mucho eso, pues funciona bien. Pero en un momento surgi\u00f3 un proyecto web donde tuve que guardar una lista de idiomas por cada participante. Usualmente solo es un idioma, pero puede haber participantes con dos (o m\u00e1s). Y me pareci\u00f3 demasiado overkill <\/i>tener una tabla para guardar los idiomas, en especial por que solo usa dos caracteres para cada idioma.<\/p>\n\n\n\n
Al final us\u00e9 un simple campo string<\/code>, y al obtener un registro de participante, le hago un explode<\/code>. Y pens\u00e9 que ser\u00eda bonito que Vendimia haga eso autom\u00e1gicamente, asi como otros tipos de conversi\u00f3n de datos desde la db (Los campos date<\/code> a un objeto Vendimia\\DateTime<\/code>, por ejemplo). Para ello necesito que el modelo sepa el tipo de cada campo.<\/p>\n\n\n\n
El problema<\/h3>\n\n\n\n
El problema es que Vendimia tiene una forma de crear y actualizar la estructura de la base de datos, ergo tiene informaci\u00f3n sobre los campos de un modelo<\/em>. Una definici\u00f3n de una tabla tiene esta forma (guardada en un fichero apps\/ventas\/db\/venta.php<\/code>):<\/p>\n\n\n\n
namespace ventas\\db;\n\nuse Vendimia\\Database\\Tabledef;\nuse Vendimia\\Database\\Field;\n\nclass venta extends Tabledef\n{\n    var $fecha_creacion = Field::DateTime;\n\n    var $tipo = [Field::FixChar, 1,\n        'index' => true,\n    ];\n\n    var $serie = [Field::SmallInt,\n        'index' => [\n            'unique' => false,\n        ]\n    ];\n\n    var $numero = [Field::Integer,\n        'index' => [\n            'unique' => false,\n        ],\n    ];\n\/\/ ...\n<\/pre>\n\n\n\n
Pero esta estructura la he creado completamente aislada del modelo, enfocada \u00fanicamente a la base de datos. A parte, los campos son simples constantes, que el motor de la base de dato lo convierte al nombre correspondiente para la base de datos.<\/p>\n\n\n\n
El problema #2<\/h3>\n\n\n\n
Este es un problema peque\u00f1o: el concepto de ‘modelo es la base de datos’ en un sistema MVC que hizo popular Django y Rails est\u00e1 mal<\/i>. Creo que un refactoring<\/i> del ORM de Vendimia tambi\u00e9n presenta una oportunidad para colocarlo en otro lado, y las clases dentro de models<\/code> ser\u00edan los services<\/i> y\/o los domain objects<\/i> de un MVC real. A mi parecer, esto ser\u00eda suficiente separaci\u00f3n.<\/p>\n\n\n\n
El problema #3<\/h3>\n\n\n\n
Este problema se llama ‘PHP’. A pesar que sus objetos han mejorado bastante en los \u00faltimos a\u00f1os, y son m\u00e1s elaborados que los de Python o Ruby, aun le falta mucha de la flexibilidad de estos dos para implementar cosas interesantes.<\/p>\n\n\n\n
Un punto en particular: PHP no tiene setter<\/i> o getters <\/i>bonitos como tiene Python (llamados Descriptors<\/em><\/span><\/a>), para poder procesar la informaci\u00f3n que se guarda en cada propiedad a trav\u00e9s de un objeto, sin recurrir a m\u00e9todos m\u00e1gicos (que es lo que actualmente hago, pero no para procesar, s\u00f3lo para asignar). Ya hablamos sobre los problemas de los m\u00e9todos m\u00e1gicos, y tambi\u00e9n tengo la intenci\u00f3n de liberarme de la mayor\u00eda de ellos.<\/p>\n\n\n\n
Esto tambi\u00e9n trae el problema que no puedo definir el objeto que referencia al campo como una variable simple, por que al asignarle un valor despu\u00e9s, simplemente se borrar\u00eda el objeto. Y usar mutators<\/em> y accessors<\/em> como getName()<\/code> no me parecen muy elegantes y\/o simples (los dos pilares de Vendimia \ud83d\ude09 )<\/p>\n\n\n\n
El futuro (con una soluci\u00f3n)<\/h2>\n\n\n\n
Entonces, ahora el ORM de Vendimia estar\u00e1 en su propio namespace<\/em>, distinto del modelo. El ORM tambi\u00e9n servir\u00e1 para obtener los campos para crear la tabla en la base de datos. Usar\u00e1 annotations<\/em> para definir los par\u00e1metros de cada campo. Un prototipo de declaraci\u00f3n ser\u00eda:<\/p>\n\n\n\n
namespace products\\orm;\n\nuse Vendimia\\ORM;\nuse Vendimia\\ORM\\Record;\n\nclass product extends Record\n{\n    \/**\n    * @V:ORM type ORM\\Char 8\n    *\/\n    private $name;\n\n    \/**\n    * @V:ORM type ORM\\Char 32\n    * @V:ORM index\n    *\/\n    private $barcode;\n\n    \/**\n    * @V:ORM type ORM\\Decimal 8, 2\n    *\/\n    private $price;\n\n    \/**\n    * @V:ORM type ORM\\Boolean\n    * @V:ORM default `True`\n    *\/\n    private $tax_affected;\n\n    \/**\n    * @V:ORM type ORM\\Array\n    * @V:ORM valid_values \"PCIE\", \"USB&lt;2\", \"FM2\"\n    *\/\n    private $requires;\n\n    \/**\n    * @V:ORM type ORM\\DateTime\n    *\/\n    private $create_at;\n\n}<\/pre>\n\n\n\n
De esta forma, los campos estar\u00e1n disponibles para autocompletaci\u00f3n de las IDEs, para validad los valores que se coloquen desde el c\u00f3digo, para formatearlos correctamente cuando vayan o venga desde o hacia la base de datos, y para crear la estructura de la tabla en ella.<\/p>\n\n\n\n
El declarar los campos ‘private<\/code>‘ depende de si al final sigo usando m\u00e9todos m\u00e1gicos, o no.<\/p>\n\n\n\n
Pros de usar m\u00e9todos m\u00e1gicos:<\/strong><\/p>\n\n\n\n