Baby Moose Makes a Stand

Its fix typo and a little programming day here in the Moose-Pen.

Before I get back on track and start working on test case '32_params.t' but before that I had to clean-up in my code. Seems I had 'parenthes' all over the place when it should really be 'parentheses' so the last thin I did last night was clean all those up. Thank goodness for Padre and it search and replace functions.

Anyway on to '32_params.t' and the fist thing I did was cut out some tests from other places and put them in there as it made a little more logical sense. From 20_where_basic.t I striped out all the tests that check params and ended with these tests;


$da->create( $utils->connect(),$container);
cmp_deeply(
$da->result()->params,
[qw(Bill Bloggings)],
"create params in correct order"
);
$da->retrieve( $utils->connect() );
cmp_deeply(
$da->result()->params,
[qw(test1 test2)],
"retrieve params in correct order"
);
$da->update( $utils->connect(),$container);
cmp_deeply(
$da->result()->params,
[qw(Bill Bloggings test1 test2)],
"update params in correct order"
);
$da->delete( $utils->connect());
cmp_deeply(
$da->result()->params,
[qw(test1 test2)],
"delete params in correct order"
);

and on my first run I get;

not ok 1 - create params in correct order
ok 2 - retrieve params in correct order
not ok 3 - update params in correct order
ok 4 - delete params in correct order

so I guess I have muddled something up over the past few days!

Well with that handy 'da_warning' flag set nice and high, I see that my SQL is coming out of the Create is


INSERT INTO people ( people.last_name ) VALUES( ? )

and given the above I did a quick run of the other tests cases and most deal fail. Time to nip that one in the bud.

Now after a good bit of blundering about I discovered that this was my bug;


my $in_hash = {
da_compose_only=>1,
view => { name => 'people' },
elements => [
{
name => 'first_name',
-- view => 'People'
++ view => 'people'
},
{
...

so a simple capitalization error. Now this may or may not be a problem, some dbs like Mongo are very very case sensitive as

use dev_db;

and

use Dev_DB;

are separate DBs and depending on where you do that 'use' you could be creating a new DB.

Others like Oracle can be or cannot be, I sure we have all run into an SQL like this


select user_name from “User”

Now I am playing with Accessor.pm correctly, as I am running into this rule

next
if (
(
$element->view ne $self->view->name
and $element->view ne $self->view->alias
)
and ( $action eq Database::Accessor::Constants::CREATE
or $action eq Database::Accessor::Constants::UPDATE )
);

from the get_dad_elements sub;

This does beg the question of what should I do for two SQL statements


INSERT INTO people ( people.first_name, people.last_name ) VALUES( ?, ? )
INSERT INTO people ( People.first_name, people.last_name ) VALUES( ?, ? )

on 99.9 of the RBDMS out there they should return the same results;

If I was Mongo or most other key data stores this would be the query


$people->insert_one( {
    "first_name" => ?,
    "last_name" => ?,
});

$People->insert_one( {
    "first_name" => ?,
    "last_name" => ?,
});


which would effect two separate collections on the data-store, not a good thing.

I was thinking maybe some sort of flag to set UC or LC off but that would only result in Database::Accessor running fine on one combination of DB and DAD and then buggering up on another combination.

The whole idea is to have a neutral platform so for now I will leave as it but I will put a big section in the POD on the importance of proper capitalization.

DSC00105a.jpg

Leave a comment

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations