[Dbix-class] Re: as_subselect_rs->delete bug?

[Rob Kinyon]

This also leads to the idea that you should be able to introspect the
$rs for various conditions, like $rs->is_read_only and $rs->has_limit
and such. Currently, these parameters are hard (and in some cases,
impossible) to introspect.

While the idea that "all resultsets are created equal" has been very
good, I don't think it can continue to stand up in the real world.

Rob

On Wed, Jul 11, 2012 at 6:47 PM, fREW Schmidt <frioux at gmail.com> wrote:
>
> On Wed, Jul 11, 2012 at 8:14 PM, Toby Corkindale <toby at dryft.net> wrote:
>>
>> On 11 July 2012 23:35, Rob Kinyon <rob.kinyon at gmail.com> wrote:
>> > On Wed, Jul 11, 2012 at 6:11 AM, fREW Schmidt <frioux at gmail.com> wrote:
>> >> I wrote a test that confirms it, but it actually has no where clause at
>> >> all
>> >> when I test it, which is even scarier.
>> >
>> > Before we go ahead confirming failures and making fixes, let's step
>> > back and discuss exactly what
>> > $rs->search(...)->as_subselect_rs->delete should actually do and if it
>> > should be something that's allowable. The point behind as_subselect_rs
>> > was to allow a resultset to be used as the RHS for a column in a
>> > search clause. If $rs->search() could detect that a $rs is the RHS,
>> > then ->as_subselect_rs() would never be called by a user. More to the
>> > point, the resultset returned by as_subselect_rs, when I designed the
>> > subquery thing, was never meant to be used as a general-purpose $rs,
>> > but only in specific contexts.
>> >
>> > So, it makes perfect sense that calling ->delete() on this
>> > special-purpose $rs wouldn't do the right thing. I am really curious
>> > as to the chain of reasoning that led to the use of
>> > ->as_subselect_rs().
>> >
>> >> Toby, as a workaround in the meantime if you remove the as_subselect_rs
>> >> it
>> >> seems to do the right thing.
>> >
>> > Of course it does the right thing. The as_subselect_rs is an error in
>> > this case.
>>
>> It looks clearly wrong in the example I gave, but inside a working
>> program you tend to be passing around variables. You can confirm that
>> they contain a ResultSet object, sure, but you don't know much more
>> than that about them.
>> But if you have a resultset, you assume you can ->search, ->count, and
>> even ->delete it.
>> What I'm saying it -- you don't always know that someone, somewhere
>> else in the code, has started calling your methods with resultsets
>> generated by ->as_subselect_rs.
>> But if you call ->delete on that $rs variable, weird and unexpected
>> things happen to the data inside your database.
>>
>> So.. while it is easy to say that I should just remove as_subselect_rs
>> from the query, please consider that DBIC should throw an error if
>> this condition occurs.
>
>
> Agreed, the options are either fix it or error; the current action is
> completely wrong.
> --
> fREW Schmidt
> http://blog.afoolishmanifesto.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/dbix-class@lists.scsys.co.uk



-- 
Thanks,
Rob Kinyon