Skip Menu |

This queue is for tickets about the DBIx-Class-Schema-Loader CPAN distribution.

Report information
The Basics
Id: 93613
Status: resolved
Priority: 0/
Queue: DBIx-Class-Schema-Loader

People
Owner: Nobody in particular
Requestors: gamesh.g [...] gmail.com
Cc:
AdminCc:

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



Subject: dbic_dump picks might_have instead of has_many
Date: Fri, 7 Mar 2014 16:22:02 +0000
To: bug-DBIx-Class-Schema-Loader [...] rt.cpan.org
From: Gil Gamesh <gamesh.g [...] gmail.com>
Hi, My set up... perl(brew) v5.16.2 DBIx::Class::Schema::Loader 0.07039 postgresql 9.1.12 system kubuntu 13.10 on i686 I have a person table and a person_address table, where person -> person_address is a one-to-many relationship. In the address table, I need to allow for partial information, so NULL is allowed in most of the fields. But I'd also like to have unique constraints across the address fields so that the table doesn't fill up with duplicates. I use a technique I found here (http://stackoverflow.com/questions/8289100/create-unique-constraint-with-null-columns) that makes an index using coalesce on each address field to do that. This works very nicely as regards preventing duplicates but has the side effect that when I refresh my DBIx::Class::Schema using dbic_dump the person to person_address relationship is might_have instead of has_many. I attach a minimal example as a bash script. Is this a bug? Or just too much to expect of dbic_dump that it navigate its way through the index to see what's going on? Many thanks for such massively useful and labour-saving software, G.
Download TestCase.sh
application/x-sh 1k

Message body not shown because it is not plain text.

Thanks for the report. This is now fixed in git by the following commit: commit b32f8189f71d9a756c645c7288f74d4f9f61b74d Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Date: Fri Apr 4 16:27:22 2014 +0100 Skip dumping unique indexes with expressions (RT#93613) DBD::Pg 3.0.0 returns expression indexes from ->statistics_info, with COLUMN_NAME => undef and pg_expression => $expression. Because ->_table_uniq_info just skipped individual rows without COLUMN_NAME, an index contains a mix of plain columns and expressions would generate erroneous ->add_unique_constraint() calls. https://github.com/dbsrgits/dbix-class-schema-loader/commit/b32f818
The fix is included in 0.07040, now available on CPAN.