Note to self...

When getting objects from a has_many member of a Class::DBI object in a Template Toolkit template, remember that the objects are returned in list context, not scalar. You get an array, not an iterator, so you have to use a foreach loop and not a while loop.

Help save the Internet

Congress, being the asshats they are, will screw up the internet soon, if they are not stopped.

Please go here and get involved.

Brendi's questions

My ex is.... irrelevant, I'm happily married.

Maybe I should.... finish the documentation on the application I've been writing for what seems like forever so I can ship the damn thing.

I love.... my wife.

I don't understand...... Apple's Sequence Grabber API.

I lost my..... mind. Oh, wait, there it is...

People would say that I'm.... a grumpy old fuck? I dunno...

Love is.... magic

Somewhere, someone is.... laughing

I will... try and get finish that damn documentation

Forever is.... a long time

I never want to.... die alone

I think the current President is..... evil

When I wake up in the morning I... need a shower

Life is full of... annoying bullshit

My past... is past

I get annoyed when... don't get me started

I wish... my Dad wasn't dying

Tomorrow I'm going to.... enjoy my first anniversary with Vicki

I have low tolerance for people who... are full of shit

Sometimes I want to... say 'fuck it' and just drop out

I am looking forward to... finishing the fucking documentation for the application I've been writing for what seems like forever

Development notes

I promise, I will finish writing up our trip to New Zealand. Really.

But right now I need to rant and make some notes for future reference.

First off, anyone who values having many development options available and the ability to adapt to new languages and technologies should avoid SQL Server like the plague that it is. Choosing SQL Server immediately limits your choices with respect to what languages you can use, and what platforms you can use with them. If your webservers are not windows boxes and you have SQL Server databases you have a very limited and limiting choice of technologies to choose from, and those that are available suffer from limitations and quirks that require significant effort to work around.

While you can get a lot of milage out of using FreeTDS and and ODBC layer like unixODBC, you will find that there are many SQL Server specific data types that don't work perfectly, problems using stored procedures, problems with inserts and updates in some languages. In short, it's a lot of work to get anything to work 100% and there are lots of sharp corners to snag an elbow on, which makes for brittle code.

The moral of the story? Choose a database that not only has the features you need (stored procedures, standards compliance, etc) but that also has a wide variety of language bindings to choose from.

My first choice of database would be postgresql. It's free, has lots of language bindings, lots of stored procedure language options, and has lots of features. It's scalable and performs very well.

Unfortunately my company is tied to SQL Server due to the crappy CRM software we use (another thing to think about is not using CRM software that ties you to a particular database), which happens to have a schema designed by retarded monkeys. But I digress...

Second, some notes:

• If you have to use SQL Server and want to use perl and Class::DBI you will have to use Class::DBI::MSSQL as a base class, and use ODBC to connect.
• If you use non standard data types (like 'money') you will have to override the built in insert(), find_or_create() and the accessors and mutators for those columns. The reason being that you will get errors in the FreeTDS layer when trying to insert or update those columns, as the ODBC layer treats them like varchars when they should be handled as SQL_DECIMAL columns. This means you will have to something like this to your accessor/mutator methods:

  __PACKAGE__->set_sql(
      update_price => qq{
   UPDATE __TABLE__
   SET price = CONVERT(money, ?)
   WHERE __IDENTIFIER__
   }
  );
  
  sub price {
  
      my $self  = shift;
  
      my $price = shift;
  
      if ($price) {
  
          my $sth = $self->sql_update_price;
  
          if ( $sth->execute( $price, $self->id ) ) {
  
              $self->_attribute_store( price => $price );
  
          }
  
          else {
  
              $self->_croak();
  
          }
  
      }
  
      return $self->_price_accessor;
  
  }
  
  

  Does this blow goats? You bet! But it is the only way to work around the limitations of FreeTDS and unixODBC.