A big problem is that, as I proceeded, I had no idea what I was doing for a lot of it. What I know about writing Perl modules, I know due to this workflow. Well, I knew "start with
Packageand end with
1 ;", but beyond that, not a whole lot. The web has helped this process a lot, and now I'm not too ashamed at what I have.
(Object orientation. Moose. It could use improvement and I would learn from the experience. But that isn't today's topic.)
So, by and large, I have modules handling the SQL queries, then passing hashes or hashrefs, depending on what I want. But, as I said, I was figuring out what I'm doing as I go along. I'd get the problem, think "I need these tables", write modules to interface with the tables, write programs that use the modules, fail to write tests for the modules because what tests I could imagine are either trivially stupid or highly dependent on the state of the database (I have Perl Testing on my desk and have worked through the first two chapters, so I know it's a failing, but see the note on object orientation.)
In a practical sense, if I'm dealing with a foo, I will have a table
foo_attributesconnecting with it. Then I'd write the module
get_foo_listfor a list of all the foos in the table. I can tell which tables I'm dealing with from the function name, for the most part. When it gets to the interaction of foos, bars and blees, it gets hairy, but that's why I get paid the big bucks, right?
Right now, I'm looking to document the schema and
DROP TABLE cruftbefore adding a few more features, which means what I'd like to do is look through my code base for all the modules I'm responsible for, search for all the functions I'm calling in each, and give me a list that might look something like this: