Zbigniew Lukasiak wrote: > On Thu, May 21, 2009 at 9:52 AM, Peter Rabbitson <[email protected]> > wrote: >> Zbigniew Lukasiak wrote: >>> On Wed, May 20, 2009 at 3:50 PM, Peter Rabbitson <[email protected]> >>> wrote: >>>> Greetings, >>>> >>>> RC2 turned out to contain a serious issue - so we present RC3. >>>> Sorry for the trouble and thanks for testing! >>>> http://rabbit.us/diff/DBIx-Class-0.08102_07.tar.gz >>> 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). _______________________________________________ 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]
