Final, Estimated Django 1.2 release date

Over the last few weeks, Django contributors have been working hard finding and fixing bugs from 1.2 Beta 1.  The RC release has been set at around May 3, and final release May 10.  There are a couple of patches still to be completed, more here.

That being said, it also means that I am only a few weeks (hopefully) from completing one of my sites, mentioned in my last news post.  Although the site is not yet finished and there is still quote a lot to do, a lot of the code is in place, so I can start writing the tutorials.

A design is being completed and finalised by a friend of mine.  He doesn’t yet have his own site, but when he does and if I remember, I will add a link.  Things that will be used in this site;

This is the first site I have coded using the 960 grid system (although 2nd version) and this is also the first design Oli has done using it, if he gets some time, hopefully he will get me a quick post explaining some of the design process.

Also, Facebook connect code has been completed……for Django 1.1.  Although there should be no need to change much, there maybe some things I change, ie use of the new Messages framework.  This will be decided in the near future.

The Django & MooTools tutorials I promised.

No, they are not here yet, and I havn’t forgotten.  With Django 1.2 being out shortly I decided to redo parts of the site to reflect changes in the framework, some of which were mentioned in a previous post.  I would also like to review all of the new features, some changes and remove anything which will be Deprecated shortly.

I also stated the tutorials would cover MooTools.  Due to the fact I need to learn how to use jQuery in the fairly near future, I’ve decided I will use this for starting.  Granted the tutorials may not be the best, but will be far easier for beginners to understand, being one myself.  I will probably write the same things in MooTools over time as it is (at the moment) still my framework of choice.

Django 1.2 Beta 1 – Some new features

So far, I have been impressed by the beta for Django 1.2.  With the official version due later this month I was ready to try out some of it for a site I’m working on.  By the time I’m finished, 1.2 will be officially out so I can just update it then and make any changes necessary from the beta to full version.

I wrote a quick post on Django Rocks earlier mention 3 key features I have been testing. Here it is.  There is also a mention do the Django debug toolbar, which I highly recommend everyone use during development.

As a side note, I’d also like to announce I will soon be setting up another blog for myself (now available at piggeh.net). Not technical at all, just the other parts of my life which really don’t join at all with the development side.  It’s all Anime, Games, Movies maybe stuff on music.  They relate to some of the other sites I have built, currently own, or am building.

Indexing your database fields – when and why.

This is fairly straightforward.  Indexing improves the performance of your database when doing certain things in your queries, including ORDER BY, WHERE and JOIN….among others I’m sure.

Indexing fields allows your database to reference a, well, index.  Think of it literally as the index at the back of a book.  It’s order alphabetically, and your given a page number.  The very same logic applies to the database.

Whenever you are going to ORDER by a field or any sort of lookup against a field, i.e WHERE my_field = 1; you want it indexed.  Your database will then refer to the indexes, find the rows it needs, in the correct order if necessary and in turn, returns the content for those rows.   Without indexing every row of data is checked every time, just like flicking through an entire book to find 1 paragraph.

There is caching available in some database languages, however you should not be relying on it, when a simple index is worth far more.

Different types of index

Primary, Unique, Index & Full-text.  For some databases, or even installations of MySQL, there are others available ie Spatial.

Each type has a different use.

  • Primary, most often this is an auto-incrementing id.
  • Unique, as it states data you require to be unique, username for example
  • Index, not required to be unique but you add for performance, something like the date a user signed up for displaying the latest user on your site.  A Django example is available on djangorocks.com
  • Full-text, allows full-text searching of text fields
  • Spatial, used for geometry based data to be stored and compared.  Depending on the database this is only 1 of many indexing types.

Naming your Database Tables & Fields

If you are working on your own projects, a lot of the following really does not necessarily apply…however when working with a team missing off some of these basics will not make you the most liked person. Please note, these are my own preferences, that I also utilise while working with a small team.

Reserved Words

Don’t use reserved words. Although you are able to use the back-tick to be able to query tables & fields using, using reserved words isn’t really smart. When looking over your own SQL code to debug or a problem or optimise the fields, it really doesn’t help when you see

SELECT `name`, `from` FROM `from` WHERE `from` = 'England';

A list of reserved words is available at http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-reservedwords-5-1.html

Descriptive Names

Where possible, try to use descriptive words. When looking over the structure of your table in phpmyadmin (for example) you want to be able to know what the field or table is used for.

SELECT * FROM `category`; +----+---------+---------+-----------------------+-------------+ | id | title | slug | description | total_posts | +----+---------+---------+-----------------------+-------------+ | 1 | Example | example | A description ....... | 0 | +----+---------+---------+-----------------------+-------------+

The only real problem with this is when you come to using JOIN’s. When using PHP’s mysql_fetch_assoc() function, having identical field names across your 2 or more tables means you will only be getting 1 title. At this point you need to use AS to you can turn title into category_title and post_title. There is an example with AS in the Pluralisation section.

CamelCase, Under_scores, Hy-phens

Personally, I would use underscores. I’ll leave that one to you, however once you start, stick to it. It is rather annoying having inconsistency.

Pluralisation

This isn’t so much of a problem, mainly just a personal preference.

I name my database tables similar to as follows;

  • category
  • post
  • author

It makes more sense when doing a JOIN when reading, as follows

SELECT
    `post`.`title` AS `post_title`,
    `category`.`title` AS `category_title`
FROM `post`
LEFT JOIN `category` ON (`post`.`category_id` = `category`.`id`)
WHERE `post`.`id` = 1;

As opposed to
SELECT
    `posts`.`title` AS `post_title`,
    `categories`.`title` AS `category_title`
FROM `posts`
LEFT JOIN `categories` ON (`posts`.`category_id` = `categories`.`id`)
WHERE `posts`.`id` = 1;

In most cases you will be JOINing a single post to a single category. It also saves a few characters.

Foreign Keys

When defining foreign keys, as in the example above, when I reference the category in my post table, I use category_id. I use this both as a reference to the table I am running the JOIN statement with, as well as the field the JOIN takes place on.

Dansette