It does not work as a document for has_many

[bokutin]

Hello.

I tried the example of has_many read POD. http://search.cpan.org/~gshank/DBIx-Class-ResultSet-RecursiveUpdate-0.34/lib/DBIx/Class/ResultSet/RecursiveUpdate.pm#Treatment_of_has_many_relations

Example of "Passing hashrefs:" worked. But cases of "Passing ids:" did not work.

It was confirmed by adding code to t/01_basic.t.

% git diff
diff --git a/t/01_basic.t b/t/01_basic.t
index 8f31dde..db89bfd 100644
--- a/t/01_basic.t
+++ b/t/01_basic.t
@@ -282,6 +282,16 @@ is( $schema->resultset('Address')->search( { user_id => $user->id } )->count,
 $dvd = $dvd_rs->find(1);
 is( $dvd->get_column('owner'), $user->id, 'foreign key set' );

+$user_rs->recursive_update({
+    id      => $user->id,
+    address => {
+        street => "101 Main Street",
+        city   => "Podunk",
+        state  => "New York"
+    },
+    owned_dvds => [ 1 ]
+});
+
 # has_many where foreign cols are nullable
 my $available_dvd_rs = $dvd_rs->search( { current_borrower => undef } );
 $dvd_rs->update( { current_borrower => $user->id } );

Is the output.

% prove -I lib -v t/01_basic.t
t/01_basic.t .. testing dbi:SQLite:dbname=t/var/dvdzbr.db

ok 1 - fixed_fields pre 0.21 api ok
ok 2 - fixed_fields 0.21+ api ok
...
ok 43 - the right number of addresses
ok 44 - foreign key set
DBIx::Class::ResultSet::RecursiveUpdate::recursive_update(): first parameter needs to be a hashref at t/01_basic.t line 285
# Tests were run but no plan was declared and done_testing() was not seen.
Dubious, test returned 255 (wstat 65280, 0xff00)
All 44 subtests passed

Test Summary Report
-------------------
t/01_basic.t (Wstat: 65280 Tests: 44 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=1, Tests=44,  1 wallclock secs ( 0.04 usr  0.00 sys +  0.72 cusr  0.08 csys =  0.84 CPU)
Result: FAIL

Document is correct? Or code is correct?

I would appreciate your answer.

Cheers, Tomohiro Hosaka

[bokutin]

I have waiting for reply.

[bokutin]

DBIx-Class-ResultSet-RecursiveUpdate-0.34 fail DBIx-Class-ResultSet-RecursiveUpdate-0.40 fail DBIx-Class-ResultSet-RecursiveUpdate-0.41 fail DBIx-Class-ResultSet-RecursiveUpdate-0.42 fail https://github.com/bokutin/dbix-class-resultset-recursiveupdate/tree/bokutin-master pass

[bokutin]

It still doesn't work. Passing ids: https://metacpan.org/pod/DBIx::Class::ResultSet::RecursiveUpdate#Not-all-foreign-table-columns-are-nullable

oka bokutin % git log -1
commit ebfb027231d1121ec5bccf57db9bfd8a407f4e47 (HEAD -> master, tag: 0.42, origin/master, origin/HEAD)
Author: Alexander Hartmaier 
Date:   Tue Aug 25 22:27:47 2020 +0200

    version 0.42

        - Fix side effects like change column_info and usage of each
        - Silence uninitialized value warnings
        - Fix updating many_to_many relationship helpers when the foreign
          relationship is named differently than the foreign key column
oka bokutin % git diff
diff --git a/t/01_basic.t b/t/01_basic.t
index 7c8dbeb..cce2562 100644
--- a/t/01_basic.t
+++ b/t/01_basic.t
@@ -297,7 +297,8 @@ $updates = {
         city   => "Podunk",
         state  => "New York"
     },
-    owned_dvds => [ { dvd_id => 1, }, ]
+    #owned_dvds => [ { dvd_id => 1, }, ]
+    owned_dvds => [ 1 ]
 };
 $user = $user_rs->recursive_update($updates);
 is( $schema->resultset('Address')->search( { user_id => $user->id } )->count,
oka bokutin % prove -I lib t/01_basic.t
t/01_basic.t .. testing dbi:SQLite:dbname=t/var/dvdzbr.db
t/01_basic.t .. 24/? Can't use string ("1") as a HASH ref while "strict refs" in use at /usr/home/bokutin/code/recursiveupdate/dbix-class-resultset-recursiveupdate/lib/DBIx/Class/ResultSet/RecursiveUpdate.pm line 498.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 25 just after 40.
t/01_basic.t .. Dubious, test returned 25 (wstat 6400, 0x1900)
All 40 subtests passed 

Test Summary Report
-------------------
t/01_basic.t (Wstat: 6400 Tests: 40 Failed: 0)
  Non-zero exit status: 25
  Parse errors: No plan found in TAP output
Files=1, Tests=40,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.38 cusr  0.03 csys =  0.43 CPU)
Result: FAIL