Hoping Kmail is Improved Now So that I Can Use It

I always wanted a KDE mail client for my gmail accounts for the below two reasons.

1. Support for multiple accounts
2. Better search support, at least in the local folders

I tried Kmail, first time with POP3, and the experience was confusing. Later on, I came to know that when POP3 clients don't modify the status of the mail in the server. For example, the mails read with the POP3 client, will still be marked as 'unread' in the server when accessed by another client. After knowing this, I gave Kmail another try, but using IMAP this time. Connection via IMAP actually removed this confusion, but it was so slow and painful to use. As of that time, there were a lot of people saying that the Kontact suite (thus Kmail too) was not yet ready for production. That statement indicated that Kmail was going through some serious development and gave me some hope for the future.

Though I gave up using Kmail, I still wanted to try it again due to the above two advantages. Now that an improved version of the Kontact suite has been released along with KDE 4.6.4, I am awaiting these to make it to either debian unstable (sid) to give it another try. I am excited as the release announcement specifically says that the IMAP speed has been improved, the reason why I actually quit Kmail.

Among the most noticable improvements are faster email notifications, vastly improved performance for IMAP email accounts, and ...

Lets wait until it arrives.

Handling Composite Keys Which are also Foreign Keys

Many-to-many relationships are usually resolved by having another junction table, which includes the keys from both sides of the relationship. This is a common scenario in database design. But things get slightly more complex when this junction table is referred by another entity.

Lets consider the below scenario:
There is a shop which purchases items in bulk, and resell them in smaller quantities. For example, they buy pens in units of Cartons and sell in smaller packs and pieces. Price of a unit varies as the measurement unit varies. A pack of pens has a different pricing (strategy) than an individual/piece of pen.
An invoice is issued for every sales which contains list of items, their relevant quantities and prices.

Lets say you came up with the following design to solve the above problem.

In the above diagram, Invoice_item_unit is more interesting as it represents a relationship between a junction table (item_unit) and an entity (Invoice). In Invoice_item_unit table, item_id and unit_id and invoice_number together form the the composite key which are actually foreign keys from other tables.

The first confusion here would be "Should item_id in Invoice_item_unit reference Item table, or Item_unit table?". It should be Item_unit, as that is what is involved in the relationship, not the original Item table.

The next confusion that may arise would be, since item_id and unit_id are from the same table, how do you define the SQL for the foreign key relationship. My emphasis is more on syntax, rather than concept. The solution is listed below.

ALTER TABLE invoice_item_unit ADD CONSTRAINT fk_item_unit_invoice_item_unit FOREIGN KEY (item_id, unit_id) REFERENCES `item_unit` (item_id, unit_id) ON DELETE RESTRICT,
 ADD CONSTRAINT fk_invoice_invoice_item_unit FOREIGN KEY (invoice_number) REFERENCES `invoice` (number) ON DELETE RESTRICT;

If you are using schema.yml of doctrine ORM to generate the database, handling the above underlined part may not be obvious at once. Here, is the solution.

  relations:
    ItemUnit:
      local: item_id
      foreign: item_id
      type: one
    ItemUnit_2:
      class: ItemUnit
      local: unit_id
      foreign: unit_id
      type: one
    Invoice:
      local: invoice_number
      foreign: number
      type: one

Update: The above was found using the reverse generation technique; create the tables and then create schema. But this approach seems problematic as doctrine in symfony 1.4 does not properly support this kind of a relationship. A better solution would be to assign a unique identifier to the item_unit table and refer that id in the invoice_item_unit table. This would work in symfony. Please refer the updated post to get a better picture on this.

Debian KDE Team Fully Focused on Getting 4.6.3 to Testing

The Debian KDE team is working fully focused on moving kde 4.6.3 from unstable (sid) repository to the testing (wheezy) repository. They have mentioned that they will not be working on bringing KDE 4.6.4 to unstable. Their priority is to finish off any remaining work on KDE 4.6.3 and move it to testing. Testing repository still is in KDE 4.4 and users have been waiting for an official major release for more than an years.

Given that KDE 4.7 beta1 is already released, if 4.6.3 is not pushed to testing before KDE upstream releases 4.7, users of the testing repository will be two three major versions behind. So, I feel that Team Debian KDE is focused on the right thing. Lets wait and see what happens.

Update:  KDE 4.6.3 entered testing repositories as of June 8, much quicker than I anticipated.