Moose Stuck on API

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 != 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->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 != 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??


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