CSS z-index not working

It's worth noting that z-index is only applied to absolutely positioned elements.

Arg, Perl attributes don't do what I want them to

Apparently, there is no way to get the name of a non-subroutine with an attribute. That means that if I want to annotate fields in a class for serialization, I need to identify the column for each one. On the plus side, I guess that means that I can move pass this particular hurdle (for now, at least).

Time to start again

I had thought that Attribute::Handlers was going to be the quick and easy solution to dealing with attributes for my ORM, but it turns out that it can only get the name of a subroutine with an attribute, not arrays (or hashes). I'm thinking that perhaps the solution is to (old-school) subclass Object::InsideOut and integrate with its attribute parsing code... This would also enable me to see the :Type attribute from OIO.

A roadmap for my Perl ORM

Mostly for my own purposes (and subject to modification).

0.1 Handle serializing a simple OIO class
0.2 Handle de-serializing a simple OIO class
0.3 Allow embedding classes (1-1 relationship) in a class (serialize/deserialize)
1.0 Allow 1-many, many-1, many-many relationships between classes (to separate tables, using join table if necessary)

Thoughts on ORM in Perl

One thing that I really admire from Java world is the EJB3 Persistence annotations. A class can be made persistent with a simple mark-up:

@Entity
class Foo {
   private int count;
   private String name;
   @Transient
   private int temp_var;
   ....
}

The @Entity notation indicates that the class should map to a table (unless overridden, it will use the class name as the table name). Every field then automatically maps to a column in the table (column names can be overridden) unless marked with the @Transient annotation.

I was thinking that something similar could be executed in Perl using perl attributes. I could do something like

package Foo;
use Object::InsideOut;

my @int :Field :Entity;
my @string :Field :Entity;
my @temp_var :Field;
...

Using something like Object::InsideOut seems essential for this sort of attribute-based mark-up, although perhaps I should look at Moose instead (although that does seem to have some significant performance penalties). There are some questions about how to handle exporting the serialization routines. Should I work towards a DAO solution or set up serialization routines directly in the class (perhaps as protected by default with the class making a decision about whether to provide public methods to expose these to clients.

A tutorial on attributes

The perldoc on attributes is a bit opaque, so digging about for information on how to program attributes in Perl, I managed to come across slides from a talk at london.pm Using Attributes Effectively (PDF). It suffers a bit in being only the slides and not the talk, but it does cover some things (like the handler functions) that seem to be largely undocumented elsewhere.

MySQL bench marks, comparing MyISAM to InnoDB and evaluating the performance hit of foreign keys

During an interview earlier this week, the question of how using foreign keys would impact performance on MySQL. I decided that it would be worthwhile to actually check this out in practice. I started out with a basic structure as follows:

CREATE TABLE IF NOT EXISTS `a` (
  `id` int(11) NOT NULL,
  `data` varchar(255) NOT NULL,
  `data2` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `b` (
  `id` int(11) NOT NULL,
  `a_id` int(11) NOT NULL,
  `data3` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Then added a second database where we had a foreign key:

CREATE TABLE IF NOT EXISTS `b` (
  `id` int(11) NOT NULL,
  `a_id` int(11) NOT NULL,
  `data3` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `a_id` (`a_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `b`
  ADD CONSTRAINT `b_ibfk_1` FOREIGN KEY (`a_id`) REFERENCES `a` (`id`) ON DELETE CASCADE;

And just to make things complete, I added a third database identical to the first, but using MyISAM as the engine.

The first thing is to do a data population. I wrote a perl script to generate 10,000 inserts of random data into table A, each with 0-5 random inserts into table B.
Next a selection of queries. I did 500 variations of SELECT * FROM a INNER JOIN b ON (a.id=b.a_id) WHERE a.id=?

For deletes, I deleted 500 rows, using DELETE FROM a WHERE id=?; DELETE FROM b WHERE a_id=? for the databases without the foreign key and the simple DELETE FROM a for the foreign key database.

The results for inserts:

database	insert time (s)	select time (s)	delete time (s)
InnoDB, no FK	4.5	0.25	3
InnoDB, FK	4.0	0.0	1
MyISAM	1.0	0.75	0

I had always assumed that the advantage of MyISAM over InnoDB was the opposite of what it turned out to be with this benchmark. Perhaps even more surprisingly, the foreign key version of the InnoDB database was uniformly faster than the non FK version. I would have expected to see some overhead at least in the insertion stage, but even on multiple trials, I found a consistent advantage for the foreign keys on the insertion.