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.cantr...@uk2group.com<mailto:david.cantr...@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


_______________________________________________
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

Reply via email to