Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-08-31

| Channels | #askriba index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:04 dboehmer_ joined #askriba
07:58 Relequestual joined #askriba
08:04 karjala_ joined #askriba
08:04 karjala_ Why is it considered "wrong" (I get a warning) when a foreign key of a "might_have" relationship is nullable?
08:06 karjala_ If rows aren't required to have a related row on the other table, then it seems intuitive that the foreign key field should be allowed to be null, no?
08:07 karjala_ I was wrong, my apologies. The foreign key field is not required to be not-nullable
08:44 karjala_ Hi again
08:44 karjala_ Can't might_have relationships have a "where" attribute in their definition?
08:45 karjala_ I'm writing where => {blaba => 1} in the attributes hashref and it does nothing
08:45 ribasushi they can, but it doesn't work in most cases, that's a long standing bug
08:45 ribasushi what you want to do instead is use the coderef definition syntax
08:46 ribasushi ( getting link, sec 0
08:46 ribasushi https://metacpan.org/pod/DBIx::Class::Relationship::Base#Custom-join-conditions
08:48 ribasushi karjala_: ^^
08:50 karjala_ a, thanks
09:06 karjala_ Actually, I do get a warning when a 'might_have' field that points to another table is nullable
09:06 karjala_ DBIx::Class::Relationship::HasOne::_validate_has_one_condition(): "might_have/has_one" must not be on columns with is_nullable set to true
09:07 karjala_ Is there a reason why the field should not be nullable?
09:07 karjala_ I mean, if a row just MIGHT have a related row (or it might not have one), shouldn't the field be allowed to be null to signify "no related row"?
09:11 ribasushi karjala_: you are using might_have in the wrong spot ( the naming is confusing, many make this mistake )
09:11 ribasushi you need to use belongs_to with jon_type => 'left'
09:12 ribasushi *join_type
09:12 ribasushi karjala_: show me the complete definition using some paste site, to make sure I am giving you the right answer
09:21 karjala_ ok, just a sec
09:21 karjala_ This is boss's database, I don't think I'm very allowed to show it
09:21 karjala_ I can show the definition of the relation, thjoug
09:21 karjala_ though
09:25 karjala_ ribasushi, https://pastebin.com/L26nkkyk
09:26 karjala_ Don't tell me the type of the field is wrong, I know it.
09:26 karjala_ I mean varchar instead of int
09:28 karjala_ And second question: If might_have is meant for some other use case, what is that use case?
09:32 ribasushi karjala_: sec reading...
09:34 ribasushi karjala_: here is the actual description of what happens under the hood, and what each rel-type actually means:
09:34 ribasushi https://rt.cpan.org/Public/Bug/Display.html?id=83712#txn-1187773
09:34 ribasushi karjala_: in particular read very carefully the explanation of "is_dependent"
09:39 ribasushi karjala_: if that doesn't answer your question fully: please ask more
09:40 karjala_ Thanks. I'm reading it now.
10:01 karjala_ ribasushi, I'm having trouble understanding the is_dependent paragraph. It's not clear to me. let me explain
10:01 karjala_ You say the way to explain is_dependent, is "which way would a FK constraint point"
10:02 karjala_ I guess that means that a value of 0 means one way, and a value of 1 means the opposite way
10:02 ribasushi correct
10:02 ribasushi karjala_: all relationship declarations in DBIC are "halves" - they declare only one way relation
10:03 karjala_ yes
10:03 karjala_ oh
10:03 ribasushi if you say Foo has_many Bar, this does *not* automatically imply Bar belongs_to Foo
10:03 karjala_ So a "1" means that the foreign key field is in the "self" table
10:04 karjala_ and it points to the "foreign" table
10:04 karjala_ (judging by the fact that belongs_to has it)
10:04 ribasushi yes, is_dependent means "I should not logically have a value here, without it existing somewhere else already"
10:04 karjala_ Gotta go eat with the colleagues, sorry, must leave. Talk later.
10:33 karjala_ aha
10:34 karjala_ even undef?
10:34 karjala_ like, if is_dependent = 1, then you're not allowed to hold the value undef?
10:34 ribasushi you are
10:35 ribasushi what you did with might_have - you said is_dependent => 0, which meant "someone *else* might be looking here"
10:35 ribasushi which is why DBIC warned you "this can't be right"
10:35 karjala_ oh!
10:35 karjala_ maybe I get it now
10:35 ribasushi it's very simple once you get it, the suboptimal naming makes it rather confusing though
10:37 karjala_ are is_multi and is_dependent actual relationship attributes? Or is there some way I can override them?
10:37 karjala_ you told me about join_type already
10:38 ribasushi you really shouldn't be doing that - just use the proper helper
10:39 ribasushi ( the direct answer to your quesion is: you can influence them, but there are a lot of misdesigns in that are, and therefore a lot of this stuff is very hard to get/override correctly )
10:39 karjala_ I still have a problem though.
10:39 ribasushi s/in that are/in that area/
10:40 karjala_ The database I'm going to work with by creating DBIC classes has this problem: Table A's package_id field is never null - it's emty string sometimes (and that doesn't correspond to any record in table Package)
10:41 karjala_ Will that throw an execption when I try to see the value of ->package?
10:41 karjala_ I wish I could design it from scratch
10:42 karjala_ But I'm not allowed (I think
10:42 ribasushi you simply need to use belongs_to + join_type left
10:42 ribasushi the latter means 'if you don't find anything matching - it's ok'
10:43 karjala_ nice
10:43 karjala_ and if I use join type = inner, then if you dont find anything, an error will occur?
10:44 ribasushi it depends on what are you doing
10:44 ribasushi sometimes it is an error, sometimes it is an empty resultset
10:44 karjala_ aha
10:44 ribasushi note that you do not need to specify inner - refer to the table I linked you earlier - these are the defaults for belongs_to
10:44 ribasushi ( though it doesn't hurt either )
10:44 karjala_ yes
14:21 karjala_ joined #askriba
18:34 karjala_ joined #askriba

| Channels | #askriba index | Today | | Search | Google Search | Plain-Text | summary