byterock

Well its almost programming day here in the Moose-Pen

In my last post I at least got the first test to pass. Tough it really wasn't a test of much as Driver::DBI is basically empty. I did have some time today to have a snoop about and read trhough the DBD::DBM POD and see what is what.

I discovered that by default DBD::DBM uses something called DBI::SQL::Nano which is really just a sub sub set of SQL

   DROP TABLE [IF EXISTS] <table_name>

   | CREATE TABLE <table_name> <col_def_list>

   | INSERT INTO <table_name> [<insert_col_list>] VALUES <val_list>

   | DELETE FROM <table_name> [<where_clause>]

   | UPDATE <table_name> SET <set_clause> <where_clause>

   | SELECT <select_col_list> FROM <table_name> [<where_clause>]

                                                [<order_clause>]

Well I will be able to test some of my Driver::DBI but some parts such as SQL JOINS and GROUP BY and I think variable binding can l not be tested with DBD::DBM. As well reading down a bit I see that there is only two fields allowed in a DBM table not very useful if I want to run complex SQLs.

So the use of this for testing any but the small sub-set above is not possible. Now all is not lost. As I mentioned in my last post one thing I want the Driver::DBI to do is follow though the DBI cycle, namely prepare, bind, execute, and retrieve results. Now I guess bind is out for now but using DBD::DBM will be fine for a simple CRUD test as I envisioned.

So here is the rub, to test any of the advanced features of Driver::DBI I will need some way to get the SQL back out of the system without doing any DBI function, I just want the raw query back. So I guess I will have to add a little more functionality into Database::Accessor so I will be able to test advanced SQL features.

Sorry for the post-ette for tonight, here is a cute pic for your time.