[Dbix-class] [ANNOUNCE] 0.08103 RC3 - call for testers! (whops)

[Zbigniew Lukasiak]

On Thu, May 21, 2009 at 2:08 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> On Thu, May 21, 2009 at 12:58 PM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
>> Zbigniew Lukasiak wrote:
>>> On Thu, May 21, 2009 at 9:52 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> 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/