On Thu, May 21, 2009 at 2:08 PM, Zbigniew Lukasiak <[email protected]> wrote: > On Thu, May 21, 2009 at 12:58 PM, Peter Rabbitson <[email protected]> > wrote: >> Zbigniew Lukasiak wrote: >>> On Thu, May 21, 2009 at 9:52 AM, Peter Rabbitson <[email protected]> >>> wrote: >>>> Zbigniew Lukasiak wrote: >>>>> My tests are all passing - but I noticed that resolve_condition in >>>>> ResultSource is now marked as private method and warns. I can >>>>> understand why - as it has rather tricky interface - but is there any >>>>> chance to have a public equivalent? That is something that would >>>>> compute the values of columns in the related ResultSet set when I do >>>>> $object->search_related( 'rel_name', {} )? >>>>> >>>> These interfaces were never meant to be public, thus were properly >>>> re-hidden. Please provide a justification use case of why an end >>>> user would need this method available. >>> >>> Sure - so I have an object, a relation on that object and a hash - I >>> want to get the related object as identified by the hash - and if it >>> does not exits then I need to create it. I guess this is a familiar >>> problem to you - the tricky part is when ther primary key is >>> automatically incremented by the database (or gets set from another >>> related table that has automatically incremented id - this is the >>> tricky might-have case from 96multi_create). Currently I do that by >>> using resolve_condition and checking lots of things. >>> >>> I guess it would be even better if I could just do >>> $object->find_related( 'rel_name', $hash_ref ) and get an exception if >>> the $hash_ref (and the relationship) is not enough to identify the >>> related object. Currently, as we know, find will try to do it's best >>> - but if there is not enough info - then it will return a random row >>> (and issue a warning if there are more rows matching - but catching >>> this warning is not enough because it does not need to be issued - for >>> example there can be just one row in the table). >>> >>> To be more concrete let's say that the related table has columns 'id' >>> and 'name'. >>> >>> $object->find_related( 'rel_name', { name => 'some name' } ) >>> >>> If the relation does not bind the 'id' - then this will find a random >>> row. I need to know if the relation does bind the 'id'. >>> >>> I know - this is the same old thing - but it has not been solved yet >>> in a satisfactory way (you did it in multicreate - but it uses even >>> more private calls - so I am out of luck in using your methods). >>> >> >> No it isn't. find_related should always add the relationship columns to >> the WHERE condition. Please show a standalone test-case where find_related >> returns random crap (including the generated SQL). > > I've never said that it does not add the relationship columns - it > does. The problem is with deciding if the provided data is enough > (together with the added relationship columns) for a find call. The > simple example is of a has_many relation, lets say user has_many books > - then $user->find_related( 'books', {} ) is not a correct call to > find (and in this case it will return a random book from the set the > user owns), but $book->find_related( 'owner', {} ) is a correct call. > > The example code is attached. Output (with DBIC_TRACE set) is: > > CREATE TABLE book ( > id INTEGER PRIMARY KEY NOT NULL, > name varchar(100) NOT NULL, > owner integer > ): > CREATE TABLE usr ( > id INTEGER PRIMARY KEY NOT NULL, > name varchar(100) NOT NULL > ): > INSERT INTO usr ( name) VALUES ( ? ): 'aaaa' > INSERT INTO book ( name, owner) VALUES ( ?, ? ): 'bbbb', '1' > INSERT INTO book ( name, owner) VALUES ( ?, ? ): 'bbbb', '1' > User id: 1 > SELECT me.id, me.name, me.owner FROM book me WHERE ( me.owner = ? ): '1' > DBIx::Class::Relationship::Base::find_related(): Query returned more > than one row. SQL that returns multiple rows is DEPRECATED for ->find > and ->single at find_relate_example.pl line 81 > DBSchema::Book
I was asked at IRC to add info that this is related to my work on RecursiveUpdate: http://dev.catalyst.perl.org/repos/bast/DBIx-Class-ResultSet-RecursiveUpdate/1.000/trunk :) -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
