Desarrollo de aplicaciones web (módulo 3)

Integración de bases de datos en aplicaciones web

- cómo integrar las bases de datos en los diferentes entornos en los que su aplicación puede funcionar entornos de aplicación: Es común que los equipos de desarrollo soporten varios entornos de aplicación como parte de sus actividades de desarrollo. Cada uno de estos entornos puede tener una configuración diferente dependiendo de la tarea para la cual has sido optimizados El entorno de desarrollo es el que está configurado para el ordenador del desarrollador individual, este entorno debe estar configurado para hacer el trabajo del desarrollador lo más eficiente posible En este entorno no se desea que los desarrolladores tengan que perder mucho tiempo en la configuración de servidores de bases de datos y de servidores web. Se quiere que se dediquen a escribir el código que define la aplicación, por lo tanto es preferible que el entorno de desarrollo esté configurado para gestionar los aspectos comunes de desarrollo, de modo que los desarrolladores puedan centrarse en los aspectos novedosos de la aplicación que están construyendo entorno de prueba: (test) está configurado para permitir la comprobación de la aplicación como un todo y esto podría destruir la base de datos. Lo que quiero decir con esto es que esta base de datos está configurada para probar la funcionalidad de la aplicación, para asegurarse de que la aplicación hace lo que se supone que se debe hacer. Por lo que a menudo en este entorno se utilizan datos falsos que se cargan en la base de datos antes de la prueba y luego se destruyen entorno de ensayo: (trial) este refleja el entorno de producción tal como se utiliza para la prueba final. Usted no quiere introducir los cambios en el entorno de producción al editar código antes de hacer la primera prueba de que los cambios funcionan, lo que se hace en un entorno que refleja el entorno de producción entorno de producción: entorno en el que la aplicación se desplegará Rails ajusta automáticamente a las aplicaciones para que se ejecuten en uno de los tres entornos pre construidos, y también puede usted crear sus entornos si así lo desea. - tecnologías que Rails utiliza para configurar las bases de datos asociadas a los diferentes entornos que se generan automáticamente para su aplicación DESARROLLO: Uno de los tres que proporciona Rails es el entorno de desarrollo, y en este caso las clases se recargan en cada solicitud, por lo que es útil para la depuración. Debido a esto no hay necesidad de reiniciar el servidor web. Si necesita hacer cambios en su código de modelo, vista o controlador, si hace una solicitud web, las nuevas clases se cargan automáticamente, las que acaba de editar. Además la funcionalidad de caché se desactiva y hay una gran cantidad de información de depuración que aparece en la página web cuando se encuentra un error. PRUEBA (TEST) Rails también establece un entorno de prueba o test, esto incluye una base de datos separada y pruebas automáticas que se aplican a esta base de datos, por lo que la base de datos se crea antes de la prueba y se destruye después de terminada. PRODUCCIÓN: El entorno de producción que Rails pone en marcha está optimizado para la entrega de servicios al cliente cuando se está ejecutando en este modo de producción, lo hace mediante la activación de la funcionalidad de caché y el manejo de redes de manera más eficiente. rails server inicia la aplicación en entorno de desarrollo por defecto, si desea iniciarlo en un tipo de entorno diferente, escriba rails server -e production rails server -e test rails server -e development ./config/environments muestra los entornos disponibles vaya a environments config y verá que hay tres archivos Ruby. Uno para la producción, uno para el desarrollo y uno para la prueba, las diferentes gemas que se incluyen en el entorno se especifican en el archivo de gemas. para ver en qué entorno estoy cd blog rake about y dirá environment development RAILS_ENV=production rake about esto no funcionó por lo que usé set RAILS_ENV=production y luego rake about y dirá environment production luego ejecutamos la consola de Rails rails console (o irb) y en la consola ejecutamos Rails.env => "production" ahora vamos a ver estos archivos Ruby para development, test y production en un editor de texto todos los comandos que se utilizan para configurar el entorno de desarrollo están aquí. Podemos leer todos los comentarios y ver las diferencias entre estos entornos. Si desea crear su propio entorno puede empezar por ajustar uno de estos entornos y luego almacenar el nuevo entorno con un nombre diferente en este directorio. ahora vamos a ver el archivo de gemas (en el editor de texto) blog > gemfile En la parte superior del archivo hay una lista de las gemas que vamos a tener cargadas en cada entorno y abajo hay un grupo de comandos. Development, test, significa que las gemas dentro de este bloque solo se pueden cargar dentro en entornos de desarrollo y pruebas. de nuevo en cmd cd blog rails s (es lo mismo que rails server) => Booting Puma => Rails 6.1.3.1 application starting in development * Listening on http://[::1]:3000 * Listening on http://127.0.0.1:3000 si luego salimos del servidor con Ctrl C === puma shutdown: 2021-05-06 05:42:21 +0100 === - Goodbye! Exiting luego probamos otros entornos> rails s -e production => Booting Puma => Rails 6.1.3.1 application starting in production Ctrl C y probamos de la otra manera set RAILS_ENV=production rails s => Booting Puma => Rails 6.1.3.1 application starting in production

Patrón de diseño de registro activo en Rails https://en.wikipedia.org/wiki/Active_record_pattern

Cuando se crea una aplicación de Rails y se ejecuta el andamiaje o los generadores de modelo, se proporcionan funcionalidades de registro activos ActiveRecord (uno de los ejemplos más importantes de la convención sobre configuración de Rails) Hay algunos otros lugares donde veremos el uso del módulo de registro activo. En el módulo de registro activo hay un método de conexión establecido que utiliza la información de la base de datos: ActiveRecord: :Base.establish_connection y usa la información en ./config/database.yml con el fin de establecer la conexión entre la aplicación Rails y un motor de bases de datos relacionales Siempre que ejecutemos migraciones vamos a usar registros activos. hay una clase de migración en ActiveRecords que hace que una base de datos evolucione gradualmente de una manera consistente con el tiempo. rake db:migrate Las migraciones nos ayudan a evitar tener que modificar las bases de datos con comandos SQL, que generalmente varían de un proveedor de bases de datos a otro. Esta es lo que hace que una aplicación pueda ser independiente de una base de datos Los archivos de migración se crean en el subdirectorio db:migrate al ejecutar el generador de andamiaje, y estas migraciones actualizan la base de datos cuando se ejecuta rake db:migrate. Este comando ejecuta todas las migraciones que aún no hayan sido ejecutadas (en orden basado en la marca de tiempo asociada a cada migración) El comando rake db:schema:dump se ejecuta automáticamente después de ejecutar rake db:migrate. Este comando actualiza el archivo schema.rb que está en la carpeta db para que coincida con la estructura de la base de datos actual. esto también utiliza ActiveRecord hay un objeto de schema y el método: ActiveRecord: :Schema.define está en ./db/schema.rb es el que inspecciona la base de datos y usa un lenguaje específico de dominio para transmitir la base de datos en un formato portable (DSL domain specific language) https://guides.rubyonrails.org/getting_started.html en schema.rb también podemos ver qué atributos y que ActiveRecord object llamar (esta información no está en el código modelo sino que se extiende a través de las distintas migraciones) hay una gema que se puede usar para anotar el modelo que incluye esta información de schema, se llama annotate models se puede usar schema.rb para crear la base de datos (y es una buena práctica) y se puede cargar en cualquier base de datos que soporte ActiveRecord (es muy potente) si miramos en el código de schema.rb ActiveRecord::Schema.define activerecord es el módulo Schema es la clase y define es el modelo y esto es lo que se usa para crear el esquema esto es lo que utiliza las migraciones también si miramos el código en la carpeta db>migrate por ejemplo el archivo de create_comments.rb acá por ejemplo usa la clase Migration del módulo ActiveRecord: class CreateComments < ActiveRecord::Migration[6.1] def change create_table :comments do |t| t.references :post, null: false, foreign_key: true t.text :body t.timestamps end end end CreateComments hereda de esta clase y debajo tenés los comandos para crear la tabla de base luego miramos en código en la carpeta models>post.rb no hay mucho que ver por el momento. Sabemos que el post va a tener un título y un body, pero por el momento no lo vemos aquí, pero sí los encontramos en schema.rb class Post < ApplicationRecord end es un poco engorroso tener que ir a schema.rb cada vez que necesitás ver qué atributos tiene el modelo para esto vamos a usar la gema annotate models para anotar esta información en el modelo (en forma de comentarios) para esto vamos al archivo blog>Gemfile y allí escribimos #Annotate models gem 'annotate' y luego ejecutamos bundle update en la cmd (en la raís blog) para incluir esta gema (vas a ver que instala annotate), cuando termina ejecutás annotate y te va a decir que ha anotado 2 modelos luego si mirás de nuevo los archivos en app>models>post.rb si creamos una nueva clase que herede de ActiveRecord: :Base y le ponemos Post, va a asumir que existe una tabla en la base de datos que se llama posts (los registros activos pluralizan el nombre de la clase automaticamente y luego buscan una tabla con ese nombre pluralizado)

clave principal

El atributo id en la tabla people se llama clave principal y podemos utilizarla para establecer relaciones con otras tablas

Patrón de diseño de registro activo

Este patrón conecta la lógica de negocios el acceso a datos y el nivel de datos y le proporciona una interfaz abstracta que le permite pensar orientado a objetos. Incluso cuando usa bases de datos relacionales. Fue usado por primera vez en aplicaciones Java empresariales. Pero hoy en día se utiliza extensivamente en marcos de diseño de aplicaciones web como Rails, Play y muchos otros. Utilizando el módulo de registro activo en Rails se puede acceder a las bases de datos Rails utilizando el código estándar de Ruby en lugar de usar consultas SQL (que pueden variar ligeramente en función de la base de datos que se esté utilizando) es más fácil de entender el patrón de diseño registro activo si se tiene una idea de cómo funcionan las bases de datos relacionales. se utiliza para acceder a los datos que se almacenan en una base de datos relacional. Utilizando este patrón de diseño se puede llevar a cabo operaciones de creación, lectura, actualización y destrucción sobre los datos sin tener que pelearse con la tecnología de la base de datos subyacente (ej SQLte, MySQL, PostgreSQL, SQL Server, Oracle, ect) proporciona una abstracción últi y separa al desarrollador de las complejidades asociadas con el nivel de datos. Esta atracción facilita la capacidad de intercambiar tecnologías de bases de datos en la aplicación y el uso de diferentes bases de datos en diferentes entornos de aplicación La mayoría de las aplicaciones de hoy en día se construyen utilizando un lenguaje orientado a objetos. Y a menudo es necesario conservar datos en las bases de datos en el lado del servidor. Por lo tanto tenemos un gran problema. Hay un desajuste fundamental entre los lenguajes de programación orientados a objetos y las bases de datos relacionales El registro activo resuelve este problema. La magia asociada con el patrón de diseño de registro activo es la forma en que permite a los lenguajes orientados a objetos funcionar de forma integrada con las tecnologías de bases de datos relacionales Lo hace mediante la creación de lo que se conoce como "mapeo relacional de objetos". Que es un mapa entre construcciones de lenguaje orientado a objetos y bases de datos relacionales. El mapeo relacional de objetos proporcionado por los registros activos convierte automáticamente objetos en construcciones que se pueden almacenar en una base de datos. Y a continuación convertirlos de nuevo a construcciones orientadas a objetos una vez recuperados en la base de datos. Esto crea un efecto que se conoce como base de datos de objetos virtual, que se puede utilizar en lenguaje de programación orientado a objetos. Esto es lo que utiliza Rails para crear una base de datos de objetos virtuales dentro de su arquitectura de aplicaciones web. Los registros activos utilizan el siguiente mapeo relacional de objetos: - Mapea CLASES desde el lenguaje orientado a objetos, a TABLAS en la base de datos relacional. - Mapea los OBJETOS de la clase dada a REGISTROS dentro de la tabla (las filas de la tabla). - finalmente mapea los ATRIBUTOS asociados a una clave a VALORES de registros (es decir columnas de una tabla de una base de datos). El patrón de diseño de registro activo se proporciona el Ruby en un módulo llamado ActiveRecord. Utilizando este módulo se puede establecer una conexión con muchas bases de datos diferentes -Se pueden crear tablas de bases de datos. -Se pueden especificar asociaciones entre las tablas que corresponden a asociaciones entre clases Ruby. -Se puede establecer el mapeo relacional de objetos entre las construcciones de lenguaje orientado a objetos Ruby y las construcciones de bases de datos. -Y se pueden realizar operaciones CRUD utilizando objetos de registro activo Ruby. este patrón de diseño se implementa como módulo Ruby por lo que está disponible en rails. Y que también se usa comúnmente en otros entornos de aplicación web basados en lenguaje de programación Ruby como Sinatra.

algunos comandos

Post.all Post.first Post.find_by(1) Post.find_by_title("My First Post") p = Post.all p[0] p[1] c = Comment.all c[0] p = Post.new p.title = "New Widget" p.body = "This is a great new widget" p.save

esquema de base de datos

Rails crea las bases de datos utilizando el esquema en el archivo .irb El archivo del esquema es el resultado de ejecutar los generadores de andamiaje, y después, la instrucción rake db migrate ¿Qué es exactamente un esquema? es la estructura formal y la organización de la base de datos, es la forma en que se documenta Una base de datos se puede instanciar desde el esquema, en este caso, la base de datos en sí es lo que contiene los datos, los registros reales y el esquema son un diseño, no almacenan ningún registro Una forma muy común de representar un esquema es utilizar un diagrama de entidad-relación captura de estructura con diagrama entidad-relaci[on 1) se dibuja la primer entidad: personas y sus atributos: id int, first_name string, last_name string, address string 2) se dibuja la segunda entidad: tel[efonos y sus atributos: id int, person_id int, phone string vamos a utilizar una notación conocida como notación de pata de cuervo, crowfoot, entre las entidades de personas y teléfonos para representar una relación de uno a varios Hay muchas herramientas disponibles para crear diagramas de relaciones de entidad que almacenan los modelos entidad-relación (algunas son gratuitas y otras son bastante asequibles) Algunas de estas herramientas se pueden utilizar para: - la construcción de un esquema de un diagrama entidad-relación - generar un diagrama entidad-relación a partir de una base de datos - comparar un esquema asociado con dos bases de datos Esto último puede ser útil para determinar si el esquema asociado con una aplicación coincide con el que está en el documento de diseño. Si las actividades de diseño conducen a un nuevo esquema, se puede registrar en el documento de diseño en evolución. lista de algunas de las herramientas disponibles para crear diagramas entidad-relación mySQL Workbench Toad Data Modeler Dia Gliffy Navicat Data Modeler pgModeler nosotros vamos a usar MySQL Workbench que es gratuito y fácil de usar

Configuración de bases de datos

Uno de los elementos arquitectónicos más importantes que pueden diferir entre los diferentes entornos es la base de datos Durante el desarrollo, usted es el único que usa la aplicación. Y por lo tanto una base de datos simple es todo lo que le hace falta. Rails ajusta automáticamente el entorno de desarrollo para utlilizar SQLite. SQLite es una base de datos que no necesita configuración, esto se debe a que no utiliza servidor. Se utiliza un archivo para almacenar la base de datos en su lugar. SQLite es sencilla y simplemente funciona. Sin embargo, debido a la simplicidad de su estructura SQlite no es en general adecuada por el entorno de producción. you que simplemente no puede manejar el flujo de datos en producción. base de datos utilizada en el entorno de prueba. Durante las pruebas le gustaría poder cargar esta base de datos con datos de prueba para ver si la aplicación funciona. ¿Qué pasa con la base de datos en una aplicación de producción? En este caso está recibiendo miles de visitas, y desea que la base de datos pueda soportar esta carga. Hay dos bases de datos muy populares con calidad de producción en uso hoy en día. Una es PostgreSQL y la otra es MySQL. Las cuales se utilizan bastante en la comunidad Rails. La configuración de base de datos para la aplicación Rails en curso se especifica en el directorio de config. En un archivo llamado database.yml ./config/database.yml Un archivo YAML es un formato de serialización de datos legible por humanos: human-readable data serialization format Que fue diseñado para adaptarse fácilmente a muchos tipos comunes de datos y muchos lenguajes de alto nivel. Originalmente estas siglas significaban Yet Another Markup Language. YAML contiene nodos clave-propiedad que tienen la siguiente sintaxis: key: property Y se llaman nodos debido a que forman una estructura en árbol Vamos a echar un vistazo al archivo de base de datos YAML, se ve así: default: &default adapter: sqlite3 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> timeout: 5000 Se trata de un par clave-propiedad. La clave es default: y luego la propiedad, que es &default El sangrado o indentado es importante en YAML. Si indenta se crea un par de clave-propiedad secundario. Aquí hay tres hijos del nodo padre que está encima. El nodo padre es defalut: &default Las tabulaciones no están permitidas en YAML, así que asegúrese al crear sus archivos que utiliza espacios y no tabulaciones. Este signo ampersand que he mostrado aquí es una parte de la sintaxis de YAML. En vez de repetir un montón de nodos en el archivo YAML, se puede identificar un nodo mediante el uso de un ancla. Y esta ancla es el ampersand. Con ello se puede hacer referencia a él más tarde mediante asteriscos. y es lo que tenemos aquíÑ este signo <<: insertan el contenido de nodo definido por defecto. Lo que sucede aquí es que estos tres hijos se insertan aquí con este comando. development: <<: *default database: db/development.sqlite3 Y al final lo que está sucediendo es que las tres bases de datos están especificadas para usar la misma SQLite. Y estamos nombrando cada base de datos de manera diferente dentro de este subdirectorio de bases de datos. Lo que esto produce es que se ha definido una configuración por defecto y luego se utiliza tres veces para nuestras bases de datos de desarrollo, prueba y producción. ste es un ejemplo clásico de cómo Rails utiliza el principio DRY, no se repite a sí mismo. Note los comentarios en el archivo YAML # Warning: The database defined as "test" will be erased and # re-generated from your development database when you run "rake". # Do not set this db to the same as development or production. la base de datos de prueba se borrará cada vez que se ejecuta el rake. Así que tenga cuidado de no poner en la base de datos de prueba aquello que tenga intención de conservar.

asociaciones y validaciones

base de datos relacional: se refiere a relaciones de 1 a varios y de varios a varios cómo se agregan estas relaciones en Rails? relación de 1 a varios (ej un post puede tener varios comentarios) la clave externa está en el lado común de esta relación (en los posts) y cada comentario recibe un post ID relación de varios a varios (ej cada persona puede tener más de una dirección), para ellos teníamos 3 tablas, una para personas, otra para direcciones y una tercera para los id de las personas y los id de las direcciones - las tablas personas y direcciones tienen una relacion de una a varios con la tercera tabla relación de 1 a 1 (ej un cliente tiene un número de cuenta), la entidad cuenta recibe un customer id que es la clave externa pero no hay patas de cuervo asímismo se podría haber agregado la clave externa dentro de la entidad cliente con la account id (da igual) pero es más natural pensar que la cuenta pertenece al cliente y no el cliente a la cuenta ya vimos bastante el patrón de diseño de registro activo. Al usar el generador de andamiaje, lo que hace es preconectar el patrón de diseño activo, así una base de datos de SQLite por ej, puede almacenar posts y comentarios al mismo tiempo que se ejecutan las migraciones al mismo tiempo se puso en marcha el ORM (Object Relational Mapper) para los objetos Post y Comment, el modelo en el patrón modelo vista controlador

agregar autores a cada post y usuarios que puedan loguearse y agregar comentarios al blog

cada usuario que se loguea para agregar comentarios tendrá un registro por lo que vamos a crear el modelo usuario Nuevo ERD (Entity-Relationship Diagram) ahora tenemos 3 tablas en nuestra base de datos usuario, post y comment cada usuario puede tener varios posts cada usuario puede tener varios comments cada comment solo puede ser creado por un usuario cada post solo es creado por un usuario y cada post puede tener varios comentarios cada comentario puede pertenecer a un solo post Así que vamos a tener que migrar la base de datos para poder incluir una nueva tabla para los usuarios y también vamos a incluir atributos de clave foránea a las tablas de post y comment (para que puedan linkearse a los usuarios) 1) empezamos con el andamiaje para users rails g scaffold User first_name:string last_name:string 2) luego migramos la base de datos rails g migration AddUseridToPosts \ user:references (esto indica que va a ser una clave externa) 3) hago lo mismo para comentarios: rails g migration AddUseridToComments \ user:references 4) finalmente creamos la migración para crear una nueva tabla de usuarios rails g migration CreateUser user_id:integer username:string 5) finalmente ejecutamos la migración rake db:migrate 6) luego si todo salió bien el archivo schema.rb tendría que haberse actualizado 7) ejecutá el servidor de rails rails server y mirá el localhost en el navegador si miramos /users vemos que aparece bien pero si miramos /posts vemos que los usuarios no aparecen allí todavía lo que tenemos que hacer es a) añadir más asociaciones formales en los modelos b) arreglar el código HTML (la vista) para lo que vamos a necesitar c) c) crear un modelo posterior en la interfaz de usuario

validaciones en ActiveRecord definidas en los modelos

class Person > ActiveRecord: :Base validates_presence_of :name validates_numericality_of :age, :only_integer => true validates_confirmation_of :email validates_length_of :password, :in => 8..20 end vamos a crear un post nuevo y comprobar si es válido p = Post.new => #<Post:0x0000020264290848 id: nil, title: nil, body: nil, created_at: nil, updated_at: nil, user_id: nil> irb(main):002:0> p.valid? => true ahora vamos a poner unas validaciones en el código (en el modelo): - vamos a post.rb - allí ya habíamos puesto has_many :comments, dependent: :destroy - ahora agregamos más validaciones: validates_presence_of :title validates_presence_of :body (no podemos guardar un post a menos que tenga un title y un body) y hacemos lo mismo con los comments: belongs_to :post belongs_to :user validates_presence_of :post_id validates_presence_of :body luego reiniciamos la consola rails quite rails c creamos un nuevo post p = Post.new y verificamos si es valido p.valid? => false nos dice que no lo miramos en el navegador también rails s vamos a crear un nuevo comentario: http://localhost:3000/comments y no le damos un post_id y nos da 3 errores: Post must exist User must exist Post can't be blank

cómo hacer que los comentarios tengan automáticamente el id del post en el que son creados?

cuando agregamos comentarios anteriormente agregamos el post_id manualmente, pero no podemos esperar que los usuarios hagan esto también tenemos que asegurarnos que los comentarios queden permanentemente vinculados a ese post para que nuestro modelo tenga esta funcionalidad, tenemos que añadir asociasiones. Cada post tiene que tener su lista de comentarios asociada y cada comentario tiene que tener detallado a qué post pertenece aquí empezamos a usar la relación "pertenece a" un comentario pertenece a un post una cuenta pertenece a una persona el módulo ActiveRecord contiene métodos de clase para vincular objetos a través de claves externas estos son: uno a uno - has_one (sin clave externa) belongs_to (con clave externa) varios a uno - has_many (sin c. externa) belongs_to (con) varios a varios - has_and_belongs_to_many (sin) nada para con las claves externas para cada modelo se almacenan en una table de unión

Gestión de bases de datos

cómo gestionar en la práctica las diferentes bases de datos asociadas con una aplicación web cómo utilizar las herramientas de Rails para gestionar bases de datos (que se apoyan significativamente en la utilidad Rake) Las utilidades Rake se basan más o menos en la utilidad de units make, de ahí el nombre de Ruby Make o de forma abreviada Rake. Rake una utilidad Make para Ruby Tareas Rake disponibles en su aplicación Rails en la cmd rake -T rake -T db tareas Rake asociadas con la gestión de bases de datos rake db:create:all crea una base de datos para cada entorno Rails rake db:migrate ejecuta todas las migraciones no ejecutadas todavía rake db:seed añade (siembra) datos iniciales a la base de datos en curso rake db:seed:all sembrará con datos todas las bases de datos de la aplicación rake db:schema:load carga el esquema en la base de datos en curso carga el esquema definido en el archivo de Ruby, schema.rb en la base de datos rake db:drop:all destruye las bases de datos en todos los entornos Rails rake db:setup crea una base de datos, carga el esquema, inicializa con datos semilla rake db:reset igual que: rake db:drop db:setup es lo mismo que borrar la base de datos y hacer un setup rake db:version lista la versión en curso de la base de datos si se han ejecutado todas las migraciones, no use rake db:migrate para crear una base de datos para una aplicación puede propiciar errores el hecho de implementar una instancia de una aplicación mediante la reproducción de toda la historia de la migración. Es mejor utilizar el esquema asociado con la aplicación actual en funcionamiento y esto se encuentra en schema.rb Es mucho más simple y más rápido cargar en la base de datos una descripción de este esquema actual. Y esto se puede hacer sólo con escribir rake db:reset. Debido a que los volcados del esquema son la fuente autorizada para el esquema de la base de datos se recomienda encarecidamente que se la registre en el sistema de control de código fuente que usted utiliza para su aplicación cuando esté haciendo el trabajo de desarrollo. Cuando usted realice pruebas de la aplicación, puede volver a crear la base de datos de prueba desde el archivo de esquema haciendo rake db:test:load Los generadores de Rails crean automáticamente pruebas y las almacenan en el subdirectorio test. Por lo que los puede ver you en su aplicación (aunque no hay muchas cosas realmente ahí) Con el fin de ejecutar todas estas pruebas, sólo tiene que teclear rake test, o simplemente rake solo. Así que si escribe rake sin test, en realidad el sistema hace rake test. Es importante tener esto en cuenta. En el siguiente vídeo le voy a mostrar cómo ejecutar pruebas en el entorno de prueba.

cómo agregar o borrar atributos

el nombre de la migración se ve: AddXXXToYYY o RemoveXXXFromYYY si proporcionás una lista de atributos y tipos, se crean comandos como add_column y remove_column en el archivo de migración por ej rails g migration AddPhoneTypeToPhones phone_type:integer y esto agrega un atributo Phone Type de tipo entero si necesitás cambiar el nombre de un atributo por ejemplo de tite a title, hacés lo mismo, pero en vez de Add ponés Change rails g migration ChangeTiteToTitleInPost esto no lo cambia el nombre del atributo por completo, para hacerlo hay que ir a la carpeta migrate blog>db>migrate y vas a ver un nuevo archivo Ruby creado con el nombre que le dimos (esta es una migración) dentro hay código que contiene una clase class ChangeTitleToTiteInPosts < ActiveRecord::Migration[6.1] def change end end pero no hay código dentro, lo agregamos nosotros manualmente def change rename_column :Posts, :title, :tite end end dentro de la función escribimos el comando rename_column, el nombre de la tabla, el viejo nombre y luego el nuevo (en mi ejemplo lo estoy cambiando a tite porque no cometí un error de tipeado anteriormente) y ahora sí ejecutamos una migración para actualizar nuestra base de datos rake db:migrate ahora podés ver el archivo schema.rb para ver el nuevo nombre del atributo

dónde especificamos estas asociaciones? vamos a agregarlas en los modelos

en el archivo post.rb por ejemplo (app>models) class Post < ApplicationRecord has_many :comments end al hacer esto el archivo comment.rb debería actualizarse automáticamente (y si no lo hace, hacelo) class Comment < ApplicationRecord belongs_to :post end (notá como post es singular acá) en post.rb vamos a agregar belongs_to :user y en user.rb has_many :posts has_many :comments y en comment.rb de nuevo belongs_to :user luego ejecutamos la aplicación para ver si los cambios toman efecto la vamos a ejecutar desde la consola y no desde el navegador porque hasta este punto no hemos cambiado nada en el código html, así que la vista no va a cambiar todavía en la raíz blog rails c p = Post.all (asignamos todos los posts a un array) p[0].comments (este comando es nuevo y podemos usarlo ahora que hemos creado las asociaciones), este comando ahora nos muestra todos los comentarios asociados con el primer post y también podemos hacer: p[0].comments[0] ahora podemos indexar los comments también también podemos crear nuevos comentarios que van a estar vinculados con el post correspondiente: p[0].comments.new y vas a ver que automáticamente recibe el post_id: 1 ahora si miramos todos los comments Comment.all solo tengo 1 en este momento pero voy a agregar un par más y un par de posts también para agregar un nuevo post p = Post.new p.title = "Tercer post" p.body = "Este es el tercer post" p.save y recién ahí queda guardado (o insertado) el post en la base de datos. También se populan los campos de created at, updated at, el id etc. para mirar este post, de nuevo tenés que asignar todos los posts al array p p = Post.all p[2] y recién ahí va a aparecer Para borrar un post p[1].destroy pero al borrar un post, no se borran los comentarios, así que este es un problema en este momento para que se borren también, vamos al post.rb (el modelo) y en la línea de la asociación con comentarios, agregamos una coma y el comando dependent: :destroy has_many :comments, dependent: :destroy Ahora para agregar un comentario específicamente a este post: NO SE COMO GUARDARLO! p[2].comments.new body = "Que buen post!" hasta ahora todo lo que hemos hecho y vincular post y comment a nivel de registro activo, lo que nos falta hacer es actualizar la vista (el código HTML)

relación de varios a varios (tabla de vinculación)

entre personas y addresses tabla de vinculación Ahora tenemos una tercera tabla en nuestro modelo (direcciones). Podríamos agregar una clave externa en la tabla de personas para direcciones. Y una clave externa en la tabla de direcciones para personas. Pero hay una forma más limpia de hacer esto, creando una tabla por separado que contendrá estas claves externas entidad: addresses_people atributos: person_id y address_id (modelo creado en mySQL Workbench)

relación uno a varios

hay una relación de uno a varios entre personas y teléfonos que significa que una persona puede tener muchos teléfonos cómo normalizar la base de datos con el fin de tener en cuenta esta relación Haremos esto mediante la creación de otra tabla que almacene todos los teléfonos. La normalización de bases de datos es el proceso de reorganización de los atributos y las tablas de una base de datos relacional con el fin de reducir las redundancias. La normalización por lo general consiste en dividir las tablas de gran tamaño en tablas más pequeñas y la definición de las relaciones entre ellas puede hacer esto mediante el almacenamiento de la clave primaria de un registro como un atributo a otra tabla donde se conoce como clave externa o clave foránea En este ejemplo el identificador de personas se almacenará en la tabla de teléfonos como una clave externa ahora hay dos tablas, una para people donde john doe no esta duplicado los telefonos se han quitado de la tabla people en la tabla telefonos no tenemos nombres solo el id de la fila de la persona en la tabla people y su telefono el id de john doe se repite dos veces en la tabla teléfonos y cada registro tiene un teléfono diferente

objetivos de este módulo

identificar elementos básicos de las bases de datos relacionales - tablas, registros, atributos - cómo se usan las claves primarias y externas para establecer relaciones entre tablas conocer las relaciones de datos uno a uno, uno a varios, y varios a varios usando modelos entidad/relación - como usar tablas de unión para crear relaciones varios a varios comprender las abstracciones generales del patrón de diseño de registro activo y cómo soportan la gestión de datos en una aplicación web comprender las nociones generales de validación de datos - dónde se aplican en una app - cómo las respuestas a las llamadas encajan en el ciclo de vida del registro activo - tener conocimientos básicos de aplicaciones Rails con el fin de conectarlos a los almacenes de datos del lado del servidor - cómo especificar relaciones y validaciones de datos dentro de los modelos de Rails entender la noción general de migración de base de datos y cómo funcionan dentro de un entorno de desarrollo ágil

cómo agregar validaciones del lado del servidor? con callbacks de ActiveRecord

introducción los objetos en un sistema orientado a objetos tienen un ciclo de vida (se pueden crear, actualizar y destruir) los objetos de ActiveRecord tienen métodos que se invocan para asegurar la integridad en cada etapa de su ciclo de vida (por ejemplo no crear un nuevo usuario si este ya existe en la base de datos) y para asegurarse que todos los atributos de un objeto son válidos antes de guardarlos en la base de datos también para destruir un objeto y destruir todos los objetos que dependen de él qué son los métodos callbacks de ActiveRecord? actúan como "ganchos" en el ciclo de vida del ActiveRecord y desencadenan lógica antes o después del cambio de estado de un objeto las validaciones son un tipo de callback que se usan para asegurarse que los datos ingresados en la base de datos son válidos los métodos de creación, almacenamiento y actualización desencadenan estas validaciones, y solo van a permitir guardar un objeto ActiveRecord si es válido y luego podemos definir validaciones adicionales en nuestros métodos en los modelos

gestión de datos

manejo de bases de datos en web apps - cómo fluyen los datos en una web app? cómo instala las cosas Rails para gestionar datos? (y la mayoría de los marcos) punto de vista arquitectónico de tres niveles de una web app: qué tipos de datos se utilizan en cada uno de estos niveles? cliente web (HTML) aplicación web (lenguaje de programación orientado a objetos) fuentes de datos (capa de persistencia) este nivel se utiliza para almacenar datos que persisten de una sesión web a la siguiente las bases de datos relacionales se usan para este propósito - tablas que contienen registros que están formados por campos el protocolo para pasar datos entre el cliente web y la aplicación web es HTTP los datos se suelen recoger mediante un formulario web en el lado del cliente y después se pasan a través de HTTP al servidor web los datos de ida y vuelta entre el cliente y el servidor se transmiten en JSON (JavaScript Object Notation) las consultas SQL (Structured Query Language) se usan para almacenar datos recuperados en una base de datos relacional pero hay un problema: los datos almacenados en objetos en la app no están en el mismo formato que las tablas de las bases de datos. Para esto está el patrón de diseño de REGISTRO ACTIVO. Esto nos da una abstracción para ayudar al programador a pensar en objetos a pesar de estar usando una bse de datos relacional en el back end. Esto de hace mediante la encapsulación de las consultas SQL dentro del patrón de diseño, por lo que no hace falta usar las consultas SQL directamente. Y cómo funciona esto en Rails? el generador de código que usamos antes cuando hicimos generate scaffold, crea automáticamente las clases y los objetos necesarios para la aplicación y también las migraciones necesarias del lado de la base de datos. entonces cuando hacemos rake db:migrate se crea un esquema de base de datos que se usa para construir la base de datos relacional y todo esto se hace de manera que los patrones de diseño de registro activo son instanciados en estos dos niveles

validación de datos

proceso de asegurar que la aplicación web opera con datos limpios, correctos y útiles se usa para asegurarse que la información es almacenada en la base de datos con el mismo formato sirve para asegurarnos que los usuarios no violan las reglas de la aplicación, por ejemplo haciendo que cada comentario requiera un post id también la entrada de datos es un vector de ataque, la falta de validación de datos es una debilidad habitual en la seguridad de aplicaciones web, ya que abre posibilidades para la inyección de SQL, scripting transversal entre sitios web y ataques de desbordamiento de buffer en dónde se encuentran las validaciones en nuestro esquema de arquitectura de aplicaciones web? cliente, red, servidor web, programas/servicios, conector, base de datos para una mejor experiencia de usuario es mejor poner la validación del lado del cliente, así si hay algún problema de validación se corrije antes de mandarlo al lado del servidor HTML puede contener reglas de validación https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation también se puede usar JavaScript del lado del servidor en el lado del servidor se pueden poner reglas de validación (por ej. comprobación si ya existe) esto se puede poner en el controlador o en el modelo, pero tiene más sentido ponerlo en el modelo. Es una buena práctica de programación mantener el controlador ligero. también se pueden poner validaciones en la base de datos, esto puede ser útil si tenés muchas aplicaciones web que usan una misma base de datos

migración de base de datos

procesos ágiles: los requerimientos van evolucionando y cambiando el código va evolucionando y los modelos de datos van evolucionando, lo que significa que la estructura de base de datos también va evolucionando qué quiere decir entonces que una base de datos va evolucionando o cambiando? quiere decir que a veces hay que agregar o borrar un atributo (columna) o a veces hay que agregar o borrar completamente una tabla o incluso agregar o borrar una relación cada vez que haya un cambio en la base de datos entonces si ya tenemos datos guardado en la base de datos, y necesitamos modificar la capa persistente, tenemos que migrar la base de datos para no perder información también hay que migrar la base de datos si querés cambiar de base de datos por ejemplo de MySQL a PostgreSQL

Databases

rake db:migrate:status database: db/development.sqlite3 Status Migration ID Migration Name -------------------------------------------------- up 20210504181004 Create posts up 20210504181841 Create comments (timestamp format)

Qué ocurre en una migración?

se actualiza el esquema se crea una nueva base de datos a partir del esquema actualizado se mueven los datos de la antigua base de datos a la nueva se destruye la base de datos antigua (los marcos de aplicaciones web modernas vienen con scripts que hace esto automáticamente) por ejemplo ActiveRecord de Rails tiene esta funcionalidad para migrar base de datos Esto lo vimos al principio cuando usamos los generadores de código Rails (andamios y modelos) y vimos que crea archivos de migración y los guarda en ./db/migrate también se pueden crear archivos de migración usando: rails generate migration MigrationName los archivos de migración tienen nombres con este formato: YYYYMMDDHHMMSS_migration_name.rb

bases de datos relacionales

una de las formas más comunes de almacenamiento persistente (poder guardar los datos de manera que permanezcan de una sesión a otra) una base de datos relacional almacena colecciones de relaciones utilizando tablas, registros y atributos. cada fila de una tabla (entidad), corresponde a un registro y las columnas corresponden a los atributos o campos de este registro hay un atributo identificador id asociado con cada registro El atributo id se utiliza para identificar de forma unívoca cada registro en la tabla esto es necesario para que otras tablas se refieran a los registros de esta tabla en este ejemplo tenemos dos registros con el mismo first name, last name and address, pero lo que cambia es el teléfono. esto ilustra una relación fundamental entre los datos Concretamente hay una relación de uno a varios entre personas y teléfonos. Esta relación captura la noción de que una persona puede tener muchos teléfonos y por lo tanto necesitamos un modelo mejor para esta base de datos

Bases de datos para aplicaciones web cómo usar la tarea rake, a través de la cual hemos ido para gestionar las bases de datos de la aplicación blog.

vemos el archivo schema.rb en Atom vemos que una vez más nos recomienda que It's strongly recommended that you check this file into your version control system. ActiveRecord::Schema.define(version: 2021_05_04_181841) do create_table "comments", force: :cascade do |t| t.integer "post_id", null: false t.text "body" t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false t.index ["post_id"], name: "index_comments_on_post_id" end Hay un poco de código Ruby, aunque voy a ir un poco por encima de él, en una clase más adelante, vamos a pasar algún tiempo más entendiendo lo que hace, pero ahora solo pensemos que esto crea la tabla en una base datos, en la base de datos que está conectada a su aplicación de comentarios. debido a que utilizamos "post_id" cuando creamos este objeto comments, el sistema sabe que hay identificadores de post como identificadores foráneos almacenados en esta tabla y también añade un índice que permite una búsqueda más rápida t.index ["post_id"], name: "index_comments_on_post_id" Este índice dice que cada post puede tener un montón de comentarios asociados con él, y este índice permite que aquellos comentarios se puedan encontrar más rápido

Tarea del módulo (o semana) 3

videos pertinentes https://www.coursera.org/learn/aplicaciones-web/lecture/fcJtV/video-4-bases-de-datos-para-aplicaciones-web https://www.coursera.org/learn/aplicaciones-web/lecture/5FtdU/video-2-patron-de-diseno-de-registro-activo-en-rails https://www.coursera.org/learn/aplicaciones-web/lecture/qcC23/video-4-aplicacion-blog-iteracion-2