Skip Menu |
 

This queue is for tickets about the Parse-Taxonomy CPAN distribution.

Report information
The Basics
Id: 107705
Status: resolved
Priority: 0/
Queue: Parse-Taxonomy

People
Owner: Nobody in particular
Requestors: jkeen [...] verizon.net
ron [...] savage.net.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: RSAVAGE [...] cpan.org
Subject: Parse::Taxonomy::MaterializedPath::adjacentify() miscalculates parent IDs
Date: Sun, 11 Oct 2015 14:09:15 -0400
To: bug-Parse-Taxonomy [...] rt.cpan.org
From: James E Keenan <jkeen [...] verizon.net>
Parse::Taxonomy::MaterializedPath::adjacentify() is not calculating parent IDs correctly when the values of second- and third-level leaf columns repeat under different non-leaf nodes. Example: ##### use strict; use warnings; use Test::More qw(no_plan); { note("Test same second- and third-level leaf fields"); my @input_columns = ( qw| path letter_vendor_id is_actionable | ); my @data_records = ( ["|alpha", 1, 0], ["|alpha|able", 1, 0], ["|alpha|able|Agnes", 1, 1], ["|alpha|able|Agnew", 1, 1], ["|alpha|baker", 1, 0], ["|alpha|baker|Agnes", 1, 1], ["|alpha|baker|Agnew", 1, 1], ["|beta", 1, 0], ["|beta|able", 1, 0], ["|beta|able|Agnes", 1, 1], ["|beta|able|Agnew", 1, 1], ["|beta|baker", 1, 0], ["|beta|baker|Agnes", 1, 1], ["|beta|baker|Agnew", 1, 1], ); my $obj = Parse::Taxonomy::MaterializedPath->new( { components => { fields => \@input_columns, data_records => \@data_records, } } ); ok(defined $obj, "'new()' returned defined value"); isa_ok($obj, 'Parse::Taxonomy::MaterializedPath'); my %expected_parents = ( 1 => '', 2 => 1, 3 => 2, 4 => 2, 5 => 1, 6 => 5, 7 => 5, 8 => '', 9 => 8, 10 => 9, 11 => 9, 12 => 8, 13 => 12, 14 => 12, ); my $adjacentified = $obj->adjacentify(); ok($adjacentified, "'adjacentify() returned true value"); my %observed_parents = map { $_->{id} => $_->{parent_id } } @{$adjacentified}; is_deeply(\%observed_parents, \%expected_parents, "Got expected parent_ids"); } ##### t/005-adjacentify.t .. # Test same second- and third-level leaf fields ok 1 - 'new()' returned defined value ok 2 - An object of class 'Parse::Taxonomy::MaterializedPath' isa 'Parse::Taxonomy::MaterializedPath' ok 3 - 'adjacentify() returned true value not ok 4 - Got expected parent_ids # Failed test 'Got expected parent_ids'Parse::Taxonomy::MaterializedPath::adjacentify() is not calculating parent IDs correctly when the values of second- and third-level leaf columns repeat under different non-leaf nodes. Example: ##### use strict; use warnings; use Test::More qw(no_plan); { note("Test same second- and third-level leaf fields"); my @input_columns = ( qw| path letter_vendor_id is_actionable | ); my @data_records = ( ["|alpha", 1, 0], ["|alpha|able", 1, 0], ["|alpha|able|Agnes", 1, 1], ["|alpha|able|Agnew", 1, 1], ["|alpha|baker", 1, 0], ["|alpha|baker|Agnes", 1, 1], ["|alpha|baker|Agnew", 1, 1], ["|beta", 1, 0], ["|beta|able", 1, 0], ["|beta|able|Agnes", 1, 1], ["|beta|able|Agnew", 1, 1], ["|beta|baker", 1, 0], ["|beta|baker|Agnes", 1, 1], ["|beta|baker|Agnew", 1, 1], ); my $obj = Parse::Taxonomy::MaterializedPath->new( { components => { fields => \@input_columns, data_records => \@data_records, } } ); ok(defined $obj, "'new()' returned defined value"); isa_ok($obj, 'Parse::Taxonomy::MaterializedPath'); my %expected_parents = ( 1 => '', 2 => 1, 3 => 2, 4 => 2, 5 => 1, 6 => 5, 7 => 5, 8 => '', 9 => 8, 10 => 9, 11 => 9, 12 => 8, 13 => 12, 14 => 12, ); my $adjacentified = $obj->adjacentify(); ok($adjacentified, "'adjacentify() returned true value"); my %observed_parents = map { $_->{id} => $_->{parent_id } } @{$adjacentified}; is_deeply(\%observed_parents, \%expected_parents, "Got expected parent_ids"); } ##### t/005-adjacentify.t .. # Test same second- and third-level leaf fields ok 1 - 'new()' returned defined value ok 2 - An object of class 'Parse::Taxonomy::MaterializedPath' isa 'Parse::Taxonomy::MaterializedPath' ok 3 - 'adjacentify() returned true value not ok 4 - Got expected parent_ids # Failed test 'Got expected parent_ids' # at t/005-adjacentify.t line 293. # Structures begin differing at: # $got->{9} = '6' # $expected->{9} = '8' 1..4 # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Test Summary Report ------------------- t/005-adjacentify.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.03 cusr 0.00 csys = 0.05 CPU) Result: FAIL # at t/005-adjacentify.t line 293. # Structures begin differing at: # $got->{9} = '6' # $expected->{9} = '8' 1..4 # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Test Summary Report ------------------- t/005-adjacentify.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.03 cusr 0.00 csys = 0.05 CPU) Result: FAIL
CC: RSAVAGE [...] cpan.org
Subject: Re: Parse::Taxonomy::MaterializedPath::adjacentify() miscalculates parent IDs
Date: Mon, 12 Oct 2015 12:13:27 +1100
To: James E Keenan <jkeen [...] verizon.net>, bug-Parse-Taxonomy [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Download (untitled) / with headers
text/plain 410b
Hi James The problem is this line in adjcentify: $depth_name_id{$depth}{$name} = $rowhash{id}; which assumes names are unique within a given depth. To make something unique, I think there are only 2 choices: o A singleton - the materialized path itself o A pair - (something about the parent, $name) I'll have a think about it, but I suspect you can solve this before I can. -- Ron Savage - savage.net.au
CC: RSAVAGE [...] cpan.org
Subject: Re: Parse::Taxonomy::MaterializedPath::adjacentify() miscalculates parent IDs
Date: Mon, 12 Oct 2015 12:13:27 +1100
To: James E Keenan <jkeen [...] verizon.net>, bug-Parse-Taxonomy [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Download (untitled) / with headers
text/plain 410b
Hi James The problem is this line in adjcentify: $depth_name_id{$depth}{$name} = $rowhash{id}; which assumes names are unique within a given depth. To make something unique, I think there are only 2 choices: o A singleton - the materialized path itself o A pair - (something about the parent, $name) I'll have a think about it, but I suspect you can solve this before I can. -- Ron Savage - savage.net.au
Download (untitled) / with headers
text/plain 704b
On Mon Oct 12 00:09:07 2015, ron@savage.net.au wrote: Show quoted text
> Hi James > > The problem is this line in adjcentify: > $depth_name_id{$depth}{$name} = $rowhash{id}; > which assumes names are unique within a given depth. > > To make something unique, I think there are only 2 choices: > o A singleton - the materialized path itself > o A pair - (something about the parent, $name) > > I'll have a think about it, but I suspect you can solve this before I can. >
Ron, thanks for keeping an eye on this. I cc-ed you because I feared you might have been relying on adjacentify() in a production context. Can you take a look at CPAN version 0.14? It should solve the problem. Thank you very much. Jim Keenan
Subject: Re: [rt.cpan.org #107705] Parse::Taxonomy::MaterializedPath::adjacentify() miscalculates parent IDs
Date: Tue, 13 Oct 2015 09:38:55 +1100
To: bug-Parse-Taxonomy [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Hi James On 12/10/15 22:25, James E Keenan via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=107705 > > > On Mon Oct 12 00:09:07 2015, ron@savage.net.au wrote:
>> Hi James >> >> The problem is this line in adjcentify: >> $depth_name_id{$depth}{$name} = $rowhash{id}; >> which assumes names are unique within a given depth. >> >> To make something unique, I think there are only 2 choices: >> o A singleton - the materialized path itself >> o A pair - (something about the parent, $name) >> >> I'll have a think about it, but I suspect you can solve this before I can. >>
> > Ron, thanks for keeping an eye on this. I cc-ed you because I feared you might have been relying on adjacentify() in a production context. > > Can you take a look at CPAN version 0.14? It should solve the problem.
Yes, it does. My problem was also assuming the output would preserve the (implicit) index numbers of the input data. It'd be good if that part of the docs, re serial, could be clarified. Otherwise, issue closed. Thanx. -- Ron Savage - savage.net.au


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.