Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-09-01

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

All times shown according to UTC.

Time Nick Message
01:51 ilbot2 joined #askriba
01:51 Topic for #askriba is now Where random Perl5-related questions get definitive answers. Currently no preset business hours due to low demand: just highlight my name and I'll answer ASAP \o/
04:04 dboehmer joined #askriba
06:26 karjala_ joined #askriba
08:03 Relequestual joined #askriba
14:41 karjala_ When defining relationship between tables, is "where" attribute broken in every case? Or is it broken only in might_have & has_one?
14:42 karjala_ Is it buggy, I mean
14:44 karjala_ I'm trying to use it in has_many, but whatever I write in where, it doesn't restrict anything.
14:45 ribasushi karjala_: it is broken for all types of relationships
14:45 ribasushi it works reliably on ->related_resultset
14:45 ribasushi and doesn't in all other cases
14:46 ribasushi karjala_: essentially - forget the attribute exists, use the extended coderef syntax I showed you earlier
14:46 karjala_ yes, i remember that
14:46 karjala_ thanks
14:46 karjala_ It'll get fixed when development is resumed, right?
14:46 ribasushi ( a lot of code relies on the case where 'where' works, hence why it wasn't properly deprecated yet: there were much more pressing things to fix )
14:46 ribasushi karjala_: on my end - eventually yes it will be
14:47 karjala_ Is the fork going to be fully compatible with dbic?
14:47 karjala_ Or will some things change?
14:47 karjala_ I imagine might_have could change a bit
14:48 ribasushi karjala_: I have no interest in changing anything - my first and foremost obligation is to existing deployments
14:48 karjala_ ok
14:49 ribasushi arguably the entire debate on ownership arose because folks kept pushing "this and that could change a bit", with not much regard to who else might be affected
14:49 ribasushi karjala_: anyway - let's pause this conversation until I actually am able to use PAUSE again
14:49 karjala_ yes
15:00 karjala_ am I safe if I use a ->has_one relationship, from self.pk to foreign.some_field ?
15:00 karjala_ nothing broken there, right?
15:03 karjala_ my test shows it's all good
15:04 ribasushi has_one is almost certainly not what you want, as I noted in the writeup on RT couple days ago
15:04 ribasushi has_one means "not only the far side makes no sense without me, I also can not exist without the far side"
15:04 ribasushi generally you want either:
15:04 ribasushi has_many <=> belongs_to
15:04 ribasushi OR
15:04 ribasushi might_have <=> belongs_to
15:10 karjala_ So I think you're saying that: we should use belongs_to if the self field can be null, or might_have otherwise
15:10 karjala_ correct?
15:10 karjala_ no sorry
15:11 karjala_ ok, scrap what I said
15:11 karjala_ In my case has_one is really what I need!
15:15 ribasushi it 99.99% is not
15:16 ribasushi give me the names of the results on both sides
15:16 ribasushi <karjala_> So I think you're saying that: ... <--- no, you are misunderstanding again, let me put it differently
15:16 ribasushi 1. Forget has_one exists
15:16 ribasushi 2. Always think of relationships as "2 sides": one is_dependent = 1 the other is_dependent = 0
15:17 ribasushi 3. on the is_dependent = 1 *always* *invariably* use belongs_to ( with join_type => 'left' if the local foreign keys are nullable )
15:17 ribasushi 4. on the other ( non-dependent ) side either use has_many or might_have depending if the "belonger" is just one or many
15:17 ribasushi 5. that's it
15:17 ribasushi karjala_: ^^
15:20 karjala_ Ok!
15:23 karjala_ Thanks
15:29 karjala_ How does "is_dependent" affect SQL generation?
15:29 karjala_ I mean, what changes between belongs_to with join_type->left, and might_have?
15:30 karjala_ Not that I intend to stray from your previous guidelines... just trying to understand
15:32 ribasushi the sql generation does not change, but the *metadata* on which DBIC decides *when* / *if* to generate something does
15:33 ribasushi karjala_: remember - if this were just a query generator: SQL::Abstract would have been sufficient
15:34 ribasushi it is the metadata that dbic has about "what does this schema actually look like *logically*", that allows many of the decisions during chaining / prefetch / result inflation / etc to be taken
15:36 karjala_ so 'prefetch' can be set automatically by dbic? It's not just the coder who can set prefetch manually?
15:37 ribasushi no, it is never set automatically
15:37 karjala_ a ok
15:37 karjala_ sorry, misunderstood you
15:37 ribasushi what prefetch does *inside* is influenced by the metadata
15:37 karjala_ I think that I have two tables, which neither is dependent on the other, yet I want to form a relation between them
15:39 ribasushi in this case ( if this is really the case ) use might_have's on both sides
15:39 karjala_ I think neither is dependent, because both have rows that don't have corresponding row on the other side, while their field is not null
15:39 karjala_ Am I right that neither is dependent?
15:40 karjala_ I mean both tables have values in their fields that don't have a match on the other side
15:41 karjala_ Thank you!
15:41 ribasushi hen yes - might_have on both sides ( *unless* more than one can match - in which case: has_many )
15:43 karjala_ But might_have requires the self field to always be NOT NULL?
15:43 karjala_ otherwise you get warning at startup?
15:43 karjala_ nullable => 0
15:44 karjala_ I'll check and see if it requires that or not.
15:46 karjala_ yes it does require that
15:47 karjala_ I get this warning: "This might indicate an incorrect use of those relationship helpers instead of belongs_to."
15:47 karjala_ Is there a way to disable it?
15:47 karjala_ "might_have/has_one" must not be on columns with is_nullable set to true
15:48 karjala_ or should I do: belongs_to both ways, with join_type = left?
15:51 karjala_ Is it correct to assume that both tables will have a relationship with each other? Isn't it perfectly reasonable only for one table to have a might_have?
15:52 karjala_ ok, i'll think about it a bit more
15:56 karjala_ hm... I have a new problem
15:59 karjala_ I have this hierarchy of tables in my "big" search: A ->(multi) B ->(single) C ->(single) B
15:59 karjala_ I wrote the db search as followS:
16:00 karjala_ $a->bs({field => 1})->search_related('c', undef, {prefetch => 'b'})
16:01 karjala_ where $a is an element of table A, bs is the method that fetches all related rows from table B
16:01 karjala_ This query raises an exception at database level, because the big query contains many joins, and the condition "field = 1"
16:02 karjala_ it doesn't say which table alias field belongs to
16:03 karjala_ so because table B appears twice in this query (with different alias each time), MySQL is confused as to which of the two aliases "field" is a field of
16:03 karjala_ Is there a way to solve this?
16:03 karjala_ Am I doing something wrong?
16:04 karjala_ (two separate questions)
16:06 ribasushi karjala_: so...
16:06 karjala_ I could replace field => 1 with 'me.field' => 1, but that me seems a bit arbitrary
16:06 ribasushi Isn't it perfectly reasonable only for one table to have a might_have? <--- yes, you can declare "half" a relationship, no problem with that
16:07 karjala_ ribasushi, but then isn't it also reasonable that no table is dependent on the other? and that no warning should have been produced?
16:07 karjala_ If there was a way to disable this warning, all would be fine
16:08 ribasushi on it giving you a warning - you have to disable it, as in *this* case the setting is legit ( your schema is of pretty terrible quality ): search for DBIC_DONT_VALIDATE_RELS in https://metacpan.org/pod/DBIx::Class::Relationship
16:08 ribasushi the warning is correct - there *will* be incosisntencies in the object model now, which will closely match the inconsistencies in your schema
16:08 karjala_ The schema is old, you're right.
16:09 ribasushi on your last question - dbic never infers table aliases for columns
16:09 karjala_ aha, thank you
16:09 ribasushi you have to specify them yourself
16:09 ribasushi { 'me.field' => $somevalue, 'b.field' => $another_value }
16:09 ribasushi I have to run now, will be back in some hours &
16:09 karjala_ thanks!
16:23 SysPete left #askriba
16:24 SysPete joined #askriba

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