Well I am not really sure whom to fault on that. But I am only super glad that I did double check the database constraints.
Django has this super cool feature which lets you create the tables in the database — “syncdb”. When you are using a MySQL database this is a part of what you will end up getting:
CREATE TABLE `auth_user_groups` (
`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
`user_id` integer NOT NULL REFERENCES `auth_user` (`id`),
`group_id` integer NOT NULL REFERENCES `auth_group` (`id`),
UNIQUE (`user_id`, `group_id`)
That sounds like a perfectly valid SQL statement and tables get created perfectly fine. The lines in bold indicate that there is a foreign key to another table’s column from the current table. But when I run syncdb the foreign key constraints just won’t get created on the database. I spent a whole evening trying to figure out what I might be doing wrong since everythign seemed to be perfectly alright. Finally I found the culprit after reading through MySQL Documentation.
REFERENCES specifications where the references are defined as part of the column specification are silently ignored by
InnoDB. InnoDB only accepts
REFERENCES clauses when specified as part of a separate
FOREIGN KEY specification.
I am not really sure whose fault it should be. As a user I would either want
a) MySQL to throw errors.
b) Django to generate the format that MySQL would really use and not just ignore.
I am not sure how many django developers who use MySQL really know that this is the case. If not for me using mysql in linux which defaults to using myISAM and my histrionics to make the app use InnoDB, I probably wouldnt have checked or delved deep into this.
I need to check if there is a ticket in django already for this. If not maybe this is probably the first patch I can work on for django.
Anyways, I ended up using sqlall to generate the sql statements and store it in a file and parse the file to create the alter table commands. I have put this as a django snippet in case anyone is as lazy as me to write the alter table commands manually.
Well, the people over at Django developer group are debating over the release of 1.0. You can read the thread for all the details.
There has been quite a lot of debate going on between the users and developer of Django about the release of a new version post their 0.96 release. I have been fairly comfortable developing using 0.96 version and have been pretty much a passive observer to this whole debate.
Recently I wanted to start using Review Board for doing code reviews for some of the projects/products we work on. I went to read the instructions and they list 0.97 (duhhh !!!!) as the version of Django. It pretty much meant that I had to use the Django trunk as of that day and I am not even sure against what revision Review Board was last tested. This definitely is not a good scenario to be deploying to and add to the fact that I already have a few applications running Django 0.96. Luckily the announcement comes in good time and even though I have to wait another couple of months I am super keen to be finally able to use review board in house and also to push all the other applications to make full use of the Django 1.0 features.
There has always been a debate ( read this blog post on popularising Django from 42topics) about the one killer application or a set of reusable applications that is going to get Django a lot more credibility and traction among developers and eventually the enterprise. Irrespective of whether its the killer application or the set of reusable applications , what I faced when i saw 0.97 as the supported django version is exactly the kind of things that can stop this from happening. How are people going to be using that one killer application or that set of reusable applications if they dont even know which version of django they all depend on? With this roadmap for release 1.0 Django is going to make it much more easier for that to happen.
Till then I am happy hacking on 0.96.
I have been working on web applications and web technologies pretty much for the past decade and one of the things that I have felt that is completely ignored during the design of an application is the URL design.
What made me write this post is the interesting interview with Jacob-Kaplan-Moss , one of the co-creators of Django. He talks about how URLConf system in django is one of his favourite features of django and how he obsseses over it from time to time. It is heartening to hear it from one of the core committers of Django. To me, Django has to be the most productive web application framework I have worked on till date.
Getting back to the topic in hand and why I consider URL design should be given more importance upfront.
To understand this better, we need to look at how a typical web application design & development takes place. If 37signals (creators of Basecamp, Backpack, Highrise , Campfire) are to be a good yardstick and boy oh boy they are, the whole concept starts with the UI. You work with a designer to come up with the UI to visualize the way the application is going to work, make changes based on feedback and the whole thing iterates till you are happy with the UI to start building web application. Once this is done, the developers look at the UI and figure out the overall design ( models/DB Tables, views/controllers, service layers etc) and then start implementing the same. While implementing each of these people need to communicate about what the URL of each page is going to be and how to go from one page to another. If you ever have built J2EE applications and used frameworks like struts you will totally understand the pain involved in this and the confusion it can cause.
Now lets say we start with the URL design. We know the basics of the application and what it should do. We start figuring out the first few set of URLs for the application. We then map each of these URLs to how they will look. If you are using Django, this can be easily done by using URLConf system and adding the relevant templates and a dummy method in a view that will call the relevant template for the URL. By the time the UI is done by the UI designer, all the URLs of the system are set in stone , all the templates are already written and also the dummy methods have also been created. If the Architect works with the UI developer so much the better at this stage since it will reduce some of the refactoring work later.
The developers can now concentrate on only implementing each of these view functions and not worry about building the UI and doing the correct linking etc etc etc. There are bound to be some changes when they refactor ( think multiple “applications” in Django), but if the URL design was done right, this would be a piece of cake.
For a project I worked on recently with django, this has saved me a ton of work since I was able to communicate to the team much more effectively by following this method. This will especially work the best for small teams working together.
I would definitely like to hear about other people’s experience in going about building a web application and how important/unimportant they consider URL Design.
A year back you get into one of the nastiest accidents. And next year you win the grand prix at the same venue after pulling in some amazing lap times. First ever win and that too to take you to the top of the championship. This is surely an indication that Kubica has arrived and living up to the huge expectations the BMW team has put on him. If the 7 stunning laps he put in on the super slippery surface before his second pit stop is any indication you can expect this polish to pull off some amazing races in the future.
Vettel gets a point starting from the pit lane. He seems to be one driver who does extremely well on slippery surfaces. Its a surprise none of the top teams have closed on him.
And for the sake of Formula One, its time FIA reviewed one of its rather stupid rule which destroyed Kimi’s and Hamilton’s race.
After I upgraded to Hardy from Gutsy my laptop has been extremely slow and I felt it mostly while using firefox. Somehow the perennial memory problems with firefox just made me not to look for any other reason.
Today it was getting really worse and decided to investigate it. Using “top” you only get to see memory usage on first glance and I am not really savvy with that. So I decided on using htop and found out that some /usr/bin/trackerd was taking up like 85% of the CPU. My initial thought was whether my computer has been compromised ( thanks to the “tracker” in the name). After a few searches I found this on the ubuntu forums.
Disabling the gnome session options as suggested in the forum was super helpful in bringing the system back to use. Hopefully I can be back to days when I dont have to reboot the laptop for months.
This assumes that you have installed rails on your machine. Also lot of the steps are based on what is present at RoR Wiki.
1. Download Lighttpd installer and install it. It will install at c:\lighttpd. You can start and stop lighttpd from the .bat files in the sbin directory. If starts on port 80 by default. You can find the config file under etc\lighttpd.conf
2. We need to install SCGI Rails Runner server. But before we do that install cmdparse ( 2.0.0 or greater ) and highline ( 1.0.1 or greater )
a) gem install cmdparse
b) gem install highline
c) Download the latest rails scgi gem and run gem install scgi_rails-0.4.3.gem.
3. Create your rails app ( Lets assume you created the “cookbook” app in e:\apps\railsapps\cookbook )
a) cd e:\apps\railsapps\cookbook
b) scgi_ctrl config -S ( please read up on the significance of -S option from the SCGI Rails Runner website)
c) scgi_service (scgi_ctrl doesn’t work on windows)
4) We need to now edit the configuration file for lighttp. Make the following changes
server.modules = (
server.document-root = “E:/apps/railsapps/cookbook/public”
server.errorlog = “e:/apps/railsapps/cookbook/log/lighttpd-errors.log”
server.errorlog = “e:/apps/railsapps/cookbook/log/lighttpd-access.log”
static-file.exclude-extensions = ( “.php”, “.pl”, “.fcgi”, “.scgi” )
server.error-handler-404 = “/dispatch.scgi”
scgi.server = ( “dispatch.scgi” => ((
“host” => “127.0.0.1″,
“port” => 9999,
“check-local” => “disable”
status.status-url = “/server-status”
status.config-url = “/server-config”
5. Restart the lighttpd server and you are good to go.