[Dbix-class] How to avoid find when create related records

Roman Daniel roman.daniel at davosro.cz
Sun Feb 4 13:09:24 GMT 2018


Thanks for your reply, but it does not work. Using might_have insted of
has_one makes no difference, the related record is still searched for.
Output of my script with DBIC_MULTICREATE_DEBUG.

MC MyApp::Schema::Result::Customer=HASH(0x2b23678) constructing address via
find_or_new
MC MyApp::Schema::Result::Customer=HASH(0x2b23678) inserting (name, Pavel
Petr, address_id, 2)
MC MyApp::Schema::Result::Customer=HASH(0x3098208) constructing address via
find_or_new
MC MyApp::Schema::Result::Customer=HASH(0x3098208) inserting (address_id,
2, name, Petr Pavel)

Also your example with CD and liner_notes is very different from mine. Your
related table liner_notes contains foreign key to your primary table CD,
while my related table address contains no reference to customer table. It
is the intention, because there may be more entities (customer,
business_owner, ...) storing their addresses in address table.

All I wanted from multi-creation was to create related record first without
any attempt to find it before (and reuse its id). The more I look into DBIC
code, the more it seems to me that is impossible to define relationships
that way and I will need to create the related object first manually. Am I
correct?

Roman

(I use DBIC 0.082841)


2018-02-04 10:19 GMT+01:00 Peter Rabbitson <rabbit+dbic at rabbit.us>:

> On 02/03/2018 05:05 PM, Roman Daniel wrote:
>
>      __PACKAGE__->has_one(
>>          'address',
>>          'MyApp::Schema::Result::Address',
>>          { 'foreign.address_id' => 'self.address_id' }
>>      );
>>
>>
> The correct relationship here is `might_have`, this is what confuses the
> entire multi-creation chain. Please read this comment ( not the whole
> thread ) for more info: https://rt.cpan.org/Ticket/Dis
> play.html?id=83712#txn-1187773
>
>
>      $schema->resultset('Customer')->create(
>>          {
>>              name    => $_,
>>              address => {
>>                  street => 'Axmanova 11',
>>                  city   => 'Brno',
>>              }
>>          }
>>        )
>>
>
> rabbit at Ahasver:~/devel/dbic$ grep -C2 liner_notes
> t/lib/DBICTest/Schema/CD.pm
> # tests oddball legacy syntax
> __PACKAGE__->might_have(
>     liner_notes => 'DBICTest::Schema::LinerNotes', undef,
>     { proxy => [ qw/notes/ ] },
> );
>
> rabbit at Ahasver:~/devel/dbic$ perl -It/lib -Ilib -MDBICTest -e '
>   my $s = DBICTest->init_schema;
>   $s->storage->debug(1);
>   $s->resultset("CD")->create({
>     title => "foo",
>     year => 2000,
>     artist => 1,
>     liner_notes => { notes => "foo" }
>   })
> '
> BEGIN WORK
> INSERT INTO cd ( artist, title, year) VALUES ( ?, ?, ? ): '1', 'foo',
> '2000'
> INSERT INTO liner_notes ( liner_id, notes) VALUES ( ?, ? ): '6', 'foo'
> COMMIT
>
>
> Cheers!
>
>
> _______________________________________________
> 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 at lists.scsys.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20180204/b1d84d0e/attachment.htm>


More information about the DBIx-Class mailing list