[Dbix-class] rs->find finds by all columns

[Zbigniew Lukasiak]

And here is another test that fails in current trunk version:

my $cd = $schema->resultset("CD")->first;
my $old_artistid = $cd->artist->artistid;
$cd->artist->update( { name => 'new name' } );
$schema->storage->debug(1);
my $art = $cd->update_or_create_related( 'artist', { name => 'some
other name' } );
is( $old_artistid, $art->artistid, 'artist updated not recreated' );


__OUTPUT__

SELECT me.artistid, me.name FROM artist me WHERE ( ( ( me.name = ? )
AND ( me.artistid = ? ) ) ): 'some other name', '1'
INSERT INTO artist (artistid, name) VALUES (?, ?): '1', 'some other name'
DBIx::Class::Relationship::Base::update_or_create_related(): DBI
Exception: DBD::SQLite::st execute failed: PRIMARY KEY must be
unique(19) at dbdimp.c line 403 [for Statement "INSERT INTO artist
(artistid, name) VALUES (?, ?)"] at t/61findnot.t line 16

The SQL dumped shows why the fallback does not work for belongs_to -
it searches by all columns including the column that we want to
update.

Cheers,
Zbyszek

On Jan 17, 2008 7:18 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> Another patch is attached - have a look and discuss.  It's becoming
> more and more complicated and perhaps the alternative would be
> simpler.
>
> cheers,
> Z.
>
>
> On Jan 16, 2008 1:29 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> > On Jan 16, 2008 10:54 AM, Ash Berlin <ash_cpan at firemirror.com> wrote:
> > >
> > >
> > > On Jan 16, 2008, at 9:02 AM, Zbigniew Lukasiak wrote:
> > >
> > > > Hi all
> > > >
> > > > This is a continuation of the "patch for ResultSet::find_or_new"
> > > > thread - but it's also a subject on it's own.
> > > >
> > > > It is my understanding that:
> > > >
> > > > $schema->resultset("Artist")->find({name => 'Random Girl Band'}, {key
> > > > => 'primary'});
> > > >
> > > > should never find anything - because it should search by the primary
> > > > key that is not included in the search conditions.  And I believe I am
> > > > not alone in this interpretation of the documentation - see for
> > > > example Matt's words:
> > > >
> > > >> The usual use of find_or_new is to pass a unique key plus additional
> > > >> attributes to be used for object creation (which are ignored in the
> > > >> find()
> > > >> by specifying the key attr as well).
> > > >
> > > > But if there is a row with name == 'Random Girl Band' then it will
> > > > find it.  To prove that I attach a patch for the  t/61findnot.t test.
> > > >
> > > > --
> > > > Zbigniew Lukasiak
> > > > http://brudnopis.blogspot.com/
> > > > <61findnot.diff>_______________________________________________
> > > >
> > >
> > > Seems sensible to me - the patch shows the behaviour I would *expect*.
> >
> > OK.  Patch is attached - perhaps someone would instruct me what would
> > be the right way to specify the 'FALSE' condition for the query.
> >
> > But after having done that patch I think that this is actually a very
> > corner case - and perhaps it is a bug to not include the unique keys
> > in the query when you do find and we should not do that.
> >
> > I've started this investigation because of update_or_create (and
> > find_or_create and find_or_new - all of which use the same logic).
> > They are useful in the case when you receive back some fields from a
> > web form and you want to use the same code for updating an existing
> > record and creating a new one.  But when you do find_or_create( {
> > primary_key => undef, other_col => 'some value', ... } ) then it will
> > fail in PostgreSQL and the answer was to do find_or_create( {other_col
> > => 'some value', ... } ) and, as the test case shows, this was failing
> > to do the right thing either so I was stuck.
> >
> > An alternative could be to insert DEFAULT by the PostgreSQL storage if
> > the primary key inserted is NULL (MySQL and SQLite would work fine
> > with inserting a NULL pk).
> >
> > I don't know - all I wanted was a working update_or_create method.
> >
> > --
> > Zbigniew Lukasiak
> > http://perlalchemy.blogspot.com/
> >
>
>
>
> --
>
> Zbigniew Lukasiak
> http://brudnopis.blogspot.com/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/