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.

Installing Rose::DB::Object

For the Backlog project, I was thinking this was going to be a good opportunity to also learn Rose::DB::Object, so I tried installing it via CPAN. Oops, it had some errors along the way. It turns out that SQL::ReservedWords has a dependency on Data::OptList which it doesn't declare. Installing Data::OptList solved that problem, but Rose::DB::Object is still failing its test suite:

t/db-object-manager..................7/3900 Can't locate object method "format_select_start_sql" via package "Rose::DB::__RoseDBPrivate__::Rose::DB::MySQL" at /Users/dhosek/.cpan/build/Rose-DB-Object-0.769-AXgKMz/blib/lib/Rose/DB/Object/QueryBuilder.pm line 725.
# Looks like you planned 3900 tests but only ran 827.
# Looks like your test died just after 827.
t/db-object-manager.................. Dubious, test returned 255 (wstat 65280, 0xff00)
 Failed 3073/3900 subtests 
 (less 783 skipped subtests: 44 okay)

My insomnia feels resolved, so I'll come back to this after sleep.

Update (21 April): I managed to solve the problem: Doing an install of Rose::DB::MySQL then re-trying to install Rose::DB::Object managed to do the trick.

Version control and databases

We have a practice of having a branch for each story in the sprint. This works fine with most stories, but what happens when we have stories that affect the database. I found this discussion on the topic which has some interesting reflections and comments. In general, though, my sense is that version control for databases is at best ad hoc and kludgy. RIght now we're doing something similar to Rails migrations, but handled manually. I'd like to formalize that process. I'm looking at DBIx::Migration::Directories, although I find no commentary on it at all, anywhere.