byterock

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.