database

There are 2 posts tagged database (this is page 1 of 1).

Delta propagation’s view-update problem

In reactive programming, the “push” implementation can take several forms of one node (computation) passing along a directed edge (a path from one node to another) some change information to another node. Two forms of change information that can be passed is:

  1. Complete node state
  2. Delta propagation

A node could pass the complete node state to the next node. The node receiving the complete state of the previous node could then use this information to compute its own new state. This is a straight-forward implementation, but it can be inefficient if the next node doesn’t need the complete state of a previous node to compute its own state.

To optimize, one could use delta propagation which only passes along the changed data of a node. This would be enough for the next node to compute its new state depending on the exact implementation.

The view-update problem occurs when a program needs to maintain the state of nodes while updating their states upon an update in data. Updates in data should only affect nodes where there is a path from the node which has a change in its data and connected nodes. In a directed acyclic graph with nodes connected with directed edges, the view of nodes passed the node with the change should be updated.

Here is an example:
node A -> node B
node B -> node C
node B -> node D

If there was an update in node B, then node views for C and D should be updated 1

The view-update problem is often described within the context of databases since relational database management system maintain different levels of views of its data. There is the external level where an end-user of a database would interact with to get data. There is the lowest level where the actual data is stored on physical hardware (disks, tape, SSDs). In between these two levels is the conceptual level which is relevant to the database software coordinating the two levels.

Each of these levels maintain their own view of the data. The external level is more interested in the data and less interested in how the data is stored on the hardware. This results in the database view-update problem. The hardware could be optimized by creating better indexes of the data or by replacing it with a faster technology. The external level should not need to know of this hardware update to generate its own view of the data.

1: For the sake of example, node A does not need to be the cause of the change in node B.

 

Easily create database records with db:seed

I have a project and a task model. Projects has many tasks. I can easily create many records of these in the database using the db/seed.rb file. In this file you can write many ActiveRecord commands to be executed when you run rake db:seed Example where the seed.rb contains

Project.create!(name: 'Project')
Project.create!(name: 'Project1')

This is will create and save two records into the database when you run rake db:seed

If you wanted to create many projects and tasks, then you would not want to be defining each record like what I had above. Instead you would want to dynamically generate as many projects and tasks as you want. The way I did it was through looping through a range in order to assign a number to the project and task attributes.

project_array = []                                                         
(1..4).each do |num|                                                       
  project_array <<  Project.create!(name: "Project#{num}")                 
end                                                                        

project_array.each do |project|                                            
  (1..20).each do |num|                                                    
    Task.create!(description: "Task#{num}", project_id: project.id)        
  end                                                                      
end

We first define the project_array to store all the created projects. We have a range passed into a block in order to generate the dynamically named project name. The project_array is then appended with Project objects.

The second loop first loops through all the projects then a range. The project loop comes first because you want to have many tasks under a few projects. In this case we are creating 20 tasks with the project_id attribute set to the project.id

This can be refactored and extended further, but for such a simple goal, no need to give it too much thought.

Rake db:reset

If you happen need to reset the database, then you do not need to run rake db:seed afterwards. rake db:reset performs the dropping, migrating, and seeding of the tables for you.