Sawyer X

After creating company-specific schemas, I decided to refactor and abstract more issues. This mainly revolved around our databases.

If you've read the previous post, and tried it yourself, you'd notice having schemas in a central module that anyone can use was comfortable. However, if you've tried to write stuff using that schema, you probably also noticed that you have to keep reinventing some variables.

Assuming OO code, you'd have an attribute for the schema object, the database host, the database user and the database password, for each of the several databases you might have. Perhaps even more variables. We had the same issue. I was tired of having to configure this every single time. The next refactor had to consider this.

I wrote a role called KittiesInc::Role::DB (assuming my $workplace was called "KittiesInc.") and it included all the attributes for databases. It created, for two databases, attributes for the schema object, database hostname, database username and database DSN.

Both schema attributes are lazy and have builders. Their builders will also check for a specified DSN (each database's DSN attribute has a predicate), and if a DSN wasn't set, it will use the hostname and username to create one. Then the password is used in order to connect to the database.

Now if I want my application to:

1. Be able to connect to our databases using ORM


2. Have all the appropriate attributes set for a user

All I have to do is add the following:

use KittiesInc::Schemas;
with 'KittiesInc::Role::DB';


That's it for now.

Next post will probably be a bit more interesting and will lead to a good closure on this front. However, I might follow that up with explaining our recent caching attempt as well.