the active record paradigm databases in database-centric web site development
Post on 02-Jan-2016
215 Views
Preview:
TRANSCRIPT
The Active Record Paradigm
Databases in Database-Centric Web Site Development
Installing Ruby on Rails
❖ Choice one: Do it yourself. Go to http://rubyonrails.org/down and follow the instructions to install Ruby, RubyGems, and Rails. It is very easy.
❖ You will also need MySQL.
Installing RoR, cont.
❖ Use a prefab version for Windows and Mac (there is also a Linux version I have never used):
❖ http://bitnami.org/stack/rubystack This gives you everything all at once.
❖ be careful to give the installer an unused port for mysql and for apache. If the defaults, 3306 and 80, are already in use, pick other numbers.
❖ This comes with the phpmyadmin web SQL gui.
Notes on Ruby on Rails
❖ Ruby on Rails has its own web servers that come with it, so you don’t need Apache, but bitnami does install apache.
❖ Ruby on Rails will work with lots of DBs, and in fact, one of the goals of RoR is to give DB independence
❖ The default port for a RonR app is 3000, but you can tell it to use others; generally, you use 3000, 3001, 3002, ...
Web Development Frameworks
❖ Moving the focus from web page design to website design
❖ All in one approach
❖ Build in MVC approach: model (db), view (html pages), Controllers (scripts)
❖ Use one perspective for building all components; in particular, use a consistent syntactic approach for Controllers, DB interactions, etc. No SQL syntax
❖ But – if you use RonRails
MVC
❖ The model is the state of the application
❖ The views are what the user sees and manipulates
❖ Controllers know how to translate between the two
❖ The MVC paradigm is very old and predates modern pixel-based displays and were originally used to model very rudimentary forms of user input.
The Big Issues
❖ SQL is a declarative, set-oriented language tied to the relational or object-relational model. SQL manipulates sets of tuples.
❖ Applications tend to be written in procedural, often object-oriented languages
So, to bridge the semantic gap...
❖ First, we use “lowest common denominator” semantics: the database must pass single fields of single tuples to the application
❖ Second, the application must pass the database tuples, and not objects
Two Choices❖ First, we could require that the application
perform this “mapping” each time
❖ Or, we could have the application adopt a limited record model that coincides with the relational model
❖ This is sometimes called “wrapping”
❖ We call this the Active Record paradigm
❖ We manipulate active records in the application and not in the db
But...
❖ This is not as much of a benefit as you might think, because the manipulations that we perform on active records look a whole lot like SQL
❖ We still do not have a data model that coincides with the application language, which in this case is Ruby, an object-oriented scripting language
Other Properties of Active Records
❖ The focus is on convention and not configuration; thus, to get the controllers (application) to talk to the models (active records are automatically mapped to tables), we only need to specify a few pieces of information
❖ A key assumption behind this approach is that relational database management systems are here to stay
How Active Objects are Manipulated
❖ Database tuples are a silent, persistent store that serves only to record the state of the application; it is not the data workspace
❖ Active Records are created by the application
❖ The application assigns/reads/updates the attributes of Active Records
❖ The Active Record is mapped to a tuple in a table in the database
But, to maintain the integrity of the
persistent store...
❖ There are explicit commands to delete records from the database itself, and is not a side-effect of deleting an Active Record, so the application programmer must be aware of the database
❖ Transactions must also be used, for the same reason
The “Convention” Approach
in Ruby on Rails❖ A table name is the plural form of the name of a
corresponding Active Record class
❖ Table names are in lower case
❖ Table names consist of one or more character strings; the strings are connected by underscores, but in a class name, the words are run together and the words are capitalized:
❖ e.g., MyItem, my_items.
Problems
❖ Putting objects in the database
❖ Using more than one database
❖ Using legacy databases
Database-Centric Apps❖ This has been a contentious issue over the
decades, and at one point, “process-centric” was considered the only intelligent way to build information-intensive systems, whether they are desktop, web-based, or distributed
❖ But now, the database is back in focus.
❖ Ironically, at the same time, we are hiding the db
❖ This creates a more unified syntax, limits configuration
❖ It also makes it easier to make db schema changes
❖ t
Other DBs you can use with RonR
❖ MySQL, Firebird, DB2, Postresql, Oracle, Openbase, Sybase, SQLite, SQL Server
❖ SQLite is a single file and very easy to install and use, but the last I used it, no FKs.
❖ Openbase is used heavily by applications that need to store data.
CRUD: Abstracting the DB
❖ Each table corresponds to a subclass of ActiveRecord::Base
❖ Create rows, reading rows, updating rows, deleting rows
❖ These update active records, not the db directly
Transactions
❖ There is a transaction method is used to execute a block of code
❖ Ar_name.transaction do...end
Ruby on Rails Overview
❖ Ruby on Rails uses the MVC paradigm
❖ Models: Active Records/Relational tables
❖ Views: HTML with embedded ruby and data from db
❖ Controllers: Ruby programs
What’s in a Ruby on Rails Application?
❖ A set of embedded folders with the skeleton of a Web application already in place
❖ That application will be available via a browser and a port:
❖ http://127.0.0.1:3000 or http://localhost:3000
❖ One of the sub-folders in our project will be “script”
❖ in that is a ruby program called “server”, which starts the app talking to port 3000 on localhost
The Folders Within a RonR Application
❖ app: views, controllers, models
❖ components: self-contained applications (with all MVC pieces)
❖ db: scripts that maintain the db, as well as sqlite dbs
❖ doc: you can automatically create code for your app
Folders, cont❖ log: for development, testing, production
❖ public: holds standard web files, for style sheets, etc.
❖ config:
❖ database.yml
❖ environment.rb
❖ routes.rb (routing of incoming requests from the web)
Folders, cont.❖ test: unit tests and such
❖ vendor: libraries from vendors, that do such things as maintain security
❖ script: programs that run various parts of your application and tools that you use while you are building your app
❖ generate (various pieces of scripting, html code, for things like controllers and scaffolding etc.)
❖ server (web)
Key Concepts❖ All in one environment for life-cycle of a web app
that minimizes configuration
❖ Large grained design philosophy (MVC)
❖ Generating code
❖ Scaffolding to build overall skeleton of the app, pre-configured - but much of this is meant to be temporary
❖ Managing the db the way you manage the rest of the app
Trade-offs
❖ One db, unless you play some tricks
❖ but you get some richer modeling capabilities
❖ Very rigid overall architecture of your app
❖ Somewhat hard to plug in other scripting languages
❖ If you want to use outside components, like apache or coldfusion, you have to do some configuring
Migrations:Providing Near-Uniform DB
Management❖ You use it from within Rails to build database
components
❖ Two things are done outside RonR
❖ Creating the db itself, more or less just giving it a name
❖ Putting test data in the db to test your app
Macintosh:projects kingbuzz$ rails expenses create create app/controllers create app/helpers create app/models create app/views/layouts create config/environments
Macintosh:projects kingbuzz$ mate expenses
top related