[Dbix-class] Are might_have relationships overly fussy?

[Marco Vittorini Orgeas]

On 07/24/2018 12:02 PM, David Cantrell wrote:
> Hello classy people!
>
> I have a result class that looks like this ...
>
>   package Database::Chimera::Result::Serviceplan;
>   use parent 'DBIx::Class::Core';
>
>   __PACKAGE__->table('serviceplan');
>   __PACKAGE__->add_columns(
>     id                   => { data_type => 'INT', is_nullable => 0 },
>     ...
>     renew_serviceplan_id => { data_type => 'INT', is_nullable => 1 },
>     ...
>   );
>   __PACKAGE__->set_primary_key('id');
>
> for this table ...
>
>   CREATE TABLE `serviceplan` (
>     `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
>     ...
>     `renew_serviceplan_id` mediumint(8) unsigned DEFAULT NULL,
>     ...
>     PRIMARY KEY (`id`)
> );
>
> In brief, a serviceplan is a description of something (a service) that
> we sell. They all have a duration, and when a service reaches the end of
> its life it can be renewed. Some renew with the same serviceplan, but
> some have to renew with different serviceplans. We encode this in the
> renew_serviceplan_id. In the case where something should renew with the
> same serviceplan, renew_serviceplan_id is null.
>
> I also have ...
>
>   __PACKAGE__->might_have(
>     "renew_serviceplan" => "Database::Chimera::Result::Serviceplan",
>     { 'foreign.id' => 'self.renew_serviceplan_id' },
>   );
>
> That warns like this, although as far as I can tell it returns exactly
> the results I need when I prefetch that relationship ...
>
> DBIx::Class::Relationship::HasOne::_validate_has_one_condition():
>   "might_have/has_one" must not be on columns with is_nullable set to
>   true (Database::Chimera::Result::Serviceplan/renew_serviceplan_id).
>   This might indicate an incorrect use of those relationship helpers
>   instead of belongs_to. at /home/dc/Chimera/dancer/../lib/Database
>   /Chimera/Result/Serviceplan.pm line 78
>
> I'm a bit surprised that it says that it *must not* be like that but
> then works anyway. I'd expect a "must not" to be fatal. Anyway ... if I
> change the relationship to a 'belongs_to' with 'join_type' => 'left' it
> shuts up, and as far as I can tell I get exactly the same data back. ie,
> belongs_to with a left join appears to be *exactly the same* as a
> might_have, just with more typing. I wonder therefore whether
> 'might_have' is being too fussy here and that warning should be got 
> rid of.
>
> -- 
> David Cantrell
> David Cantrell
> System Architect
> The Hut Group<http://www.thehutgroup.com/>
>
> Tel:
> Email: david.cantrell at uk2group.com<mailto:david.cantrell at uk2group.com>
>
> For the purposes of this email, the "company" means The Hut Group 
> Limited, a company registered in England and Wales (company number 
> 6539496) whose registered office is at Fifth Floor, Voyager House, 
> Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its 
> respective subsidiaries.
>
> Confidentiality Notice
> This e-mail is confidential and intended for the use of the named 
> recipient only. If you are not the intended recipient please notify us 
> by telephone immediately on +44(0)1606 811888 or return it to us by 
> e-mail. Please then delete it from your system and note that any use, 
> dissemination, forwarding, printing or copying is strictly prohibited. 
> Any views or opinions are solely those of the author and do not 
> necessarily represent those of the company.
>
> Encryptions and Viruses
> Please note that this e-mail and any attachments have not been 
> encrypted. They may therefore be liable to be compromised. Please also 
> note that it is your responsibility to scan this e-mail and any 
> attachments for viruses. We do not, to the extent permitted by law, 
> accept any liability (whether in contract, negligence or otherwise) 
> for any virus infection and/or external compromise of security and/or 
> confidentiality in relation to transmissions sent by e-mail.
>
> Monitoring
> Activity and use of the company's systems is monitored to secure its 
> effective use and operation and for other lawful business purposes. 
> Communications using these systems will also be monitored and may be 
> recorded to secure effective use and operation and for other lawful 
> business purposes.
>
> hgvyjuv
>
>
> _______________________________________________
> 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@lists.scsys.co.uk
Have you specified a custom join condition on that relationship which is 
not showed on the posted code? This is straight from the docs:

>  Note that if you supply a condition on which to join, and the column in
>     the current table allows nulls (i.e., has the "is_nullable" 
> attribute set
>     to a true value), than "might_have" will warn about this because it's
>     naughty and you shouldn't do that. The warning will look something 
> like:
>
>       "might_have/has_one" must not be on columns with is_nullable set 
> to true (MySchema::SomeClass/key)
>
>     If you must be naughty, you can suppress the warning by setting
>     "DBIC_DONT_VALIDATE_RELS" environment variable to a true value. 
> Otherwise,
>     you probably just meant to use "DBIx::Class::Relationship/belongs_to".
I have some memories of having experienced something similar in the 
recent past with might_have but I don't recall if I *had* actually 
specified a custom join condition or not.

In fact I can't recall at the moment if this ended up as something on my 
bug queue or not: I can imagine some occasions where NULL could be a 
problem on custom joins, but it shouldn't be worth that warning in other 
cases.

-- 
Marco