byterock

Back to the API day again here in the Moose-pen

To be extra diligent I decided to play about with some of the tests in '40_joins.t' to see if my API was working as I expected. Namly I took this link;

 {

                type       => 'LEFT',

                to         => { name => 'address' },

                conditions => [

                    { operator=>"!=",

                        left  => { name => 'id' },

                        right =>  {

                              function => 'left',

                              left     => { name => 'city_id',

--                                          view => 'address' 

                                            },

                              right    => { param => 11 }

            }

                    }

and took out that view on the function on the right and as you guessed it I got an error in my SQL

JOIN address ON people.id != LEFT(people.city_id,?) 

my Database::Accessor API did not fill in the 'view' coming from the 'to' above instead it defaulted to the view of the DA as a whole. Now the code is working because that 'address' element is in the left position only set up to work when on a right. This case however it is a left that is in a right so that makes it a right if that sounds reasonable??
Quite the dilemma!
Unfortunately there is no easy way in Moose (or most OO programming languages, except maybe Node..JS ) to know the scope of an individual class withing the larger instance of the class. So I cannot simply use something like this;

if $element->get_parent ->isa 'xxx'

To figure out where my element is coming from so I can use the correct view. There is a MooseX called MooseX::Tree that may help me but do I really want to add all that in for just this little part of the API. I could try and add a global attribute like 'parent' that I will have to somehow fill with a ref to ist container but I am also limited by the fact that I use coercion to a great degree so I would have to create some process to fill that ref-value in for me after each object is create a lot of extra work.

Not to be stymied I did try a few things and the only semi-successfult one was this little change

           $self->_check_element($element->predicates->right,1,$alias);

--         $self->_check_element($element->predicates->left,0,$alias);

++         $self->_check_element($element->predicates->left,($alias) ?1: 0,$alias);

and it was a partial fix as I got

JOIN address ON address.id != LEFT(address.city_id,?) 

Close but as we all know close only counts in horse-shoes and hand-grenades?
Well going to put my thinking cap on for this one but I think it is a loss. There is just no on solution that is going to fit as I can have almost any combination imaginable on the conditions of a join even if you could figure out that an element is on the right of a predicate there is no way to know that it is suppose to use the links view??

Maybe I will just have to downgrade my API a little??