This follows on from a previous post Beginner Rails – Creating a new application where we’re looking at a simple implementation of a photo blog.

When you create a model in rails, it generally comes stock with nothing added except for the base definition of its properties and inherited methods. Models are located in the appmodels folder of your project, and inherit ActiveRecord::Base to provide it with the database-aware behaviors.

 To illustrate how this works, we’ll implement the remaining two models from the previous post:

• Photo
• Comment

To create a model, you use the command:

rails g model ModelName propertyName1:type1 propertyName2:type2

So for the Photo model:

rails g model Photo gallery_id:integer title:string

You’ll notice that because photo belongs to a gallery, the gallery_id for that photo is created that’ll be used as a foreign key.

This creates the relevant model, tests and migration script. Use

rake db:migrate

to run the migration and create the photos table in the database

Now that the model has been created, we’ll create our first association. This association will be that a Photo belongs to a Gallery, and a Gallery can have many Photos.

To specify that a Photo belongs to a gallery, we make the change in appmodelsphoto.rb:

And now to specify a Gallery has many photos, open up appmodelsgallery.rb:

By adding two simple lines of code, ActiveRecord is now aware of the relationships between these entities and can work with objects far easier.

 Let’s go into the console and try it out:

Here we created a new gallery which creates it in memory, and then running the save() method which commits it to the database.

If you want to do the new and save procedure in one step, you can call the “create” method instead which we’ll now use to add some photos to this gallery:

So now our database has 1 gallery that has 2 photos in it. We can leverage the associations we created before to navigate these objects:

The next phase is to add the ability to create comments against these photos. The association is similar to the Gallery/Photo relationship with one addition: A comment belongs to a single photo, a photo can have many comments, and a gallery has many comments through its photos.

Let’s start by creating the Comment model:

rails g model Comment photo_id:integer body:text

rake db:migrate

Then modifying the Comment & Photo models:

And then create a new association in the Gallery model that will retrieve all of the comments for all of the photos related to it:

Once that’s done, reload the changes in your irb console by using:

reload!

And then add some comments to each photo:

Now we can try out all of our associations, including the “by relation” ones from Gallery to Comment:

In this example, we looked at belongs_to and has_many associations, but the full list of associations Rails supports is:

• has_one
• has_many
• belongs_to
• has_and_belongs_to_many

Which is enough to define any type of association you have.

This is a very simple example, but these principles can be applied at a much larger scale to sufficiently manage all of your objects. The next post will define the validations that define the data rules for each object.

First, declare a new project using the command:

rails new photoblog –d mysql

The –d mysql option tells rails to create a new project preconfigured to use mysql. It’s your choice what you use, and the complete set of choices are:

mysql/oracle/postgresql/sqlite3/frontbase/ibm_db

This generates the skeleton files needed for a rails app:

The next step is to define our database connections. Open up config/database.yml:

If you’re using a different provider, your configuration file will be different. Check over the defaults and make any necessary changes.

Once your connections have been defined, we need to create them. Rather than doing it ourselves, we’ll get rake to do this for us.

 rake db:create:all

When this finishes, you’ll notice that rake has created the databases for all environments:

So that’s the basic setup and configuration of a rails app. The next step is to create the entities for our application. In this photoblog app, we’ll create 3 entities:

We’ll have a number of galleries, that each contain some photos, and each photo can have comments attached against it.

 In development it’s easiest to create entities in order of their dependence. That is, create objects that don’t depend on anything else and work backwards from there. In this case, the entities will be created:

1. Gallery
2. Photo
3. Comment

We’ll use a process in rails called scaffolding to get the Gallery set up. Scaffolding is a quick and dirty method to get a basic set of MVC objects together to interact with an entity.

To do this for the Gallery entity, use:

rails generate scaffold Gallery title:string

2 things about this – firstly we didn’t explicitly create an id field (this is handled implicitly for all rails objects), secondly rails automatically pluralizes all of your entity names.

At this point all of these files exist, but the database doesn’t have the “galleries” table created. This is a convention of rails where models are created in a migration script (under db/migrate), and need to be applied to your database using the command:

rake db:migrate

If you open these migration scripts, you’ll notice there’s no SQL. This makes it dead easy to switch to different database providers later on without having to retrofit all of your code.

At this point you can check out your basic gallery page by booting up your web server. To get a list of all of the links in your site, use:

rake routes

By default, RoR comes bundled with a WEBrick server, so to start it up all you need to do is:

rails server

The server starts up on: http://127.0.0.1:3000, and a visit to one of the routes (eg: http://127.0.0.1:3000/galleries) can be seen in the console:

As well as your browser:

Pretty basic, unstyled site. The next post will have a deeper look into model relationships, and how to gain more control over your application development without using scaffolding.

ROR is very strongly governed by the laws of DRY (“Don’t Repeat Yourself”) and Convention over Configuration. In other words, if you develop using ROR the way it’s intended, you should see very high returns on your effort.

The basic architecture of a rails app looks like this:

These are some of the major components. A rails app includes:

• Ruby – the programming language used
• Rails – the web framework
• Web server – WEBrick is the default, but Passenger is the de facto standard for production environments
• Database – Rails interacts with many different databases through adapters. This achieves the ultimate goal of being able to switch databases at any point without changing any code.
• ActiveRecord – The standard ORM that handles the mappings of database rows to Ruby objects.
• ActiveResource – Allows ruby apps to connect to each other or other REST based web servers.
• MVC stack – The standard separation of responsibilities for the views, models and controllers implemented in a lot of different languages and frameworks

Rails also includes a bunch of other modules, tools and concepts that I haven’t touched on here for the sake of simplicity, but this should be enough to provide a basic understanding.

Ruby by itself is a very readable language. Due to a very light sprinkling of syntactic symbols is generally easy to comprehend even by non development types. This makes it ideal for development/BA types/Customers to verify correct behaviors in the code.

The selling point of ROR is the speed it takes to get a high quality site up and running quickly. This is different from many other web stacks such as ASP.NET (incl ASP.NET MVC), PHP, CF where the database is still treated very much as an “outside” component of a website that’s maintained separately.

Due to ActiveRecord, rails generation and rake migrations; each change is incremental and includes both a repeatable upgrade/downgrade task that is database agnostic.

Add to this a very test-centric approach to development, cross platform support and significantly lifting of the framework of a lot of the plumbing code, getting a serious app up and running quickly is a reality of ROR.

However, ROR is not without its disadvantages – the most popular of which is proper hosting support. Although not a shortcoming of rails in itself, many web hosts have treated rails hosting as something that just needs to be installed so it can be added on their feature sheet. The result can be very shaky rails apps. If you’re looking for a good host, consider a ruby-centric host such as:

www.hostingrails.com

www.heroku.com

www.engineyard.com

Ruby is a very simple language that’s easy to learn and easy to read. Coupled with the Rails framework results in a very fast and agile way to get web applications up and running.

If you’re a Django/Pylons/ASP.NET/JSP/PHP developer interested in what ROR has to offer, then it’s worthwhile spending a couple of days working through of the thousands of online tutorials to see how a Rails evolves.

At this point, even if you decide Rails isn’t for you, you will hopefully touch on many of the standard design principles it’s based on that can be applied to any language.

First the easy but inflexible way.

1. Create a textbox in the body of the report & set the value to what you want appearing in your header/footer
2. Set the name of your textbox to txtVarStore
3. In the properties of this textbox, set Visibility -> Hidden to True (ie: hide the textbox)
4. Create a textbox in your header/footer & set the value to the expression: “=ReportItems!txtVarStore.Value“

This will set the value of the textbox in your header/footer; but will only do it for the page that the hidden textbox is on.

The second way is a bit more involved, but persists across pages:

1. Go to Properties of your report
2. Go to the Code tab
3. Create a new public shared variable for your value, ie:
   1. Public Shared Dim MyVar as String
4. Create a new function to set the value of this variable, ie:
   1. Public Function SetMyVar ( ByVar var as String)
   2.    MyVar = var
   3. End Function
5. Create a new textbox in the body of your report & set the value to the expression:  “=Code.SetMyVar(First(Fields!colVar.Value, “DataSourceName”))”
6. Create a new textbox in your header/footer, set the value to the expression: “=Code.MyVar”

What this does is set up a new static variable (shared variable for you VB ppl), which persists once across the entire report. In SSRS, the body content gets generated first, which is why we can set the static variable using the SetMyVar function.

When it comes time for the header/footer to render, it simply reads out the value of the static variable.

Bit of a sleazy hack, but such are the quirks of SSRS

Simple scenario, I have a *csv file that I’m importing to a db table. The flat file is all text delimited using double quotes. A number of the fields contain literal double quotes, which in any CSV text delmited implementation you would normally escape by using another double quote delimeter. To illustrate:

This:

he cried out “SSIS!” in frustration

Becomes This:

“he cried out “”SSIS!”" in frustration”

Simple, standard csv behaviour, parses fine in excel.

Try importing to SSIS and your import will crash out, and if you try to preview that row you’ll get: “The flat file parser does not support embedding text qualifiers in data”

Solution? The only way I’ve found to get around this is to write your own escape functionality. I piggy-backed off html encoding and replaced literal quotes with "  , and then used derived columns with REPLACE(ImportedField,”"”,”"”) to change them back prior to putting them in their destination table.

I hate having to write work arounds like this, especially for functionality which should be part of the underlying core system. If anyone has a better way, please drop your comments in below.

Where DateTimeval is the column that holds the… date time value.

Firstly the < (15/2) part determines the range of the midpoints (ie: the midpoint 15 ranges from 7.5 to 22.5).  Next it gets the minutes part from the value (eg: 10, 49, 15, etc), then does % 15. This will give the remainders (10, 04, 00). If the remainder is less that the range value (ie: < (15/2)), then by simply subtracting the remainder from the original value will give us the midpoint (eg: N/A, 49 – 4 = 45, 15 – 0 = 15).

If, however, the remainder is > (15 / 2), then we need to add the difference of (15 – remainder) to get the upper midpoint value (eg: 10 + (15 – 10) = 5, 45, 15).

And voila, the date time values are segmented into 15 minute chunks.

Of course you can substitute 15 with however many minutes  you want to segment by (eg: 5, 10, 30 etc).

Performance has been Ok. I ran this over 200,000 records and it took about 3 seconds on a shared dev server. Not bad.

I’ve written the following SQL that will retrieve the min/max date values, and create a single record for every day in that min/max range. It’s useful to turn this sql into a view which will refresh itself automatically every time the cube calling it is processed.