Database Visualization

Keeping documentation up-to-date is always a pain in the ass. I was recently working on updating our database diagrams and thought that there may be a way to automate the process.

I found 2 solutions:

1. XMI
2. RailRoad

For solution (1), it worked, but I had to tweak it slightly. Because we are using PostgreSQL, I had a problem when UmlDumper tried to execute current_database for the adapter. This works fine for the MySQL adapter, but no such function exists for the PostgreSQL adapter. I quickly hacked it and just replaced it with a general name for our database, as we didn't have to be dead-on here.

I was quite disappointed when Dia did not know how to open up the XMI file. So, searching around, I found a program called Umbrello. It works great. Unfortunately, I had all my UML classes, but no diagram! I had to drag and drop each one individually (I couldn't figure out how to drag them all at the same time T.T). I then manually added in all the lines and made it pretty. Not too bad, but it was partly automated and partly manual.

For solution (2), it worked great. I used a rake task to generate the svg files. I had several issues with this, which was the fact that RailRoad is used to diagram models in RoR, not the database. Hence, I ended up with a lot of relations that didn't exist in the database. This meant TONS of lines. The lines are also quite hard to follow as they constantly overlap and cross each other.

2 major issues I had was that there is a 1-to-1 relationship (for efficiency purposes). However, the diagram did not reflect this. For example, we have class A and B that are in a 1-to-1 relationship. A will have has_many relationships and so will B. However, the diagram showed that all of B's has_many relationships were related to A, not B. I couldn't figure out why.

The other issue was a logged bug. If the model ends in an 's', the diagram gets messed up. The diagram will automatically drop the trailing 's'. This created incorrect relationships.

For these 2 major issues, I was unable to use solution (2) in the end. However, if more improvements are made, I may give it another chance as the whole process was completely automated. If your interested, it also does Controller diagrams.

If anyone else has a better way of producing automated diagrams of their database or models, give me a shout. I'd love to hear other solutions.


W

respond_to + render :partial

RoR has a very quick way to turn your web application into a web service that supports API hooks into your application. It does this using the respond_to method. It's as simple as doing something like:

respond_to do |format|
format.html # automatically calls the corresponding view
format.js #automatically calls the corresponding rjs
format.xml { render :xml => @user.to_xml # or other XML stuff }
end

It's that simple!

Well, there's one odd thing that got me for a little bit. I'm not sure if it's a bug, but when I tried to render a partial in the format.js block, I got an error that it could not find the corresponding template:

respond_to do |format|
format.js { render :partial => 'my_partial' }
end

I found that very odd, but not fixable... I tried adding '.html.erb' to the end of my_partial:

format.js { render :partial => 'my_partial.html.erb' }

And magic! It worked! I'm almost sure this isn't the way RoR is suppose to handle this, but in the meantime, it works! Small hack, but I'm happy :D If any one else runs into this problem, drop a comment, or even better, if you know why or how to solve this, let me know!


W

attachment_fu - Controller and View

Upload Image - after all the hard work trying configuring the damn thing, this is where it pays dividends. To create an upload form, all we need are three lines:

<% form_for(:photo, @photo, :url => some_path,
:html => { :multipart => true }) do |f| %>

<%= f.file_field :uploaded_data %> <%= submit_tag "Upload" %>

<% end %>

make sure multipart is set to true, or else it won't work.
Over to the controller side, you just do what you normally do with other create actions

def create

@photo = Photo.new params[:photo]
if @photo.save ... yayaya

and the rest will be handled by attachment_fu

Listing Images - once again, three lines

<% for pic in @photo %>
<%= link_to image_tag(pic.public_filename(:thumb)), pic.public_filename %>
<% end %>

sticking in the :thumb will grab all the thumbnails, leaving it out will grab the bigger version

example:

photo.public_filename #=> /photo/2/file.jpg
photo.public_filename(:thumb) #=> /photo/2/file_thumb.jpg

Delete Image - it's just like any other objects

@photo = Photo.find(id)
@photo.destroy


J

Customized Logger

Rails framework comes with a logger for you to log activities on your application, which is pretty handy. However, there's a problem. Your development.log or production.log (depends on which environment you are running) comes with many other informations which makes is very difficult to locate your own logs.

In order to solve this issue, we'll create a custom logger which will extend the original logger and save our own logs on a seperate file.

Open environment.rb (the reason we put it there it's because you want it available as soon as your server boots up, so you can call it whenever you need it)

go to the very bottom and add the following lines:

class CustomLogger <>
end

YOUR_CUSTOM_LOG = CustomLogger.new("/path/to/your/log/file")

and you use it just like a regular logger:

YOUR_CUSTOM_LOG.info "GOT HERE"

something worth noting is that the variable that holds the CustomLogger object must be
a global variable, or else you won't be able to access it in your controllers or models.

another thing is that make sure you create the log file ahead of time, your server won't start if the log file you specified does not exist.

when everything is set, restart your server and test it out!


J

Controllers

Next up: Controllers! Being a developer who has had experience with PHP and the .NET framework... controllers are an entirely new beast to me. At the beginning, we were thinking of splitting up login functions, view functions, etc. into separate controllers. This was the way we were used to thinking about modularizing: taking sections of the application and having that chunk as one module. It took us a while to figure out that this was completely wrong!

A controller contains a number of actions. Actions. The name in itself tells you immediately that a controller should have several actions that are common. I guess we knew that, but we didn't know what the commonality was between the actions, until an epiphany hit us. The controller controls a particular model and all the actions corresponding to this model. Therefore, the way that we had first separated our application was based on ACTIONS! Completely wrong! Reconfiguring our minds, it became clear that we should have things like a User Controller, which would handle all of the actions that were to be done on a user, such as save, edit, create, etc.

Thinking in this way takes somewhat of a brain twist, as it is completely different than what we have been taught. However, this definitely opens up new doors and new things to learn. I'm not quite sure I can say I'm fully excited about this, but I can definitely see how all the code can be separated and easily found.

We'll have to play around with the controller some more to get a feel for things, but in the mean time, hang tight and we'll keep you updated!

W