Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-10-20

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

All times shown according to UTC.

Time Nick Message
04:04 dboehmer_ joined #askriba
09:01 karjala_ joined #askriba
09:20 karjala_ ribasushi: Could you (in a future version) allow us to include many_to_many relationships inside a prefetch?
09:20 ribasushi almost certainly no
09:21 ribasushi if anything in a future version a more robust multi-hop description language will have to be made, and the current m2m system retired ( because it is mostly useless, it works correctly in a very very limited amount of cases )
09:24 ribasushi karjala_: my recommendation *today* is: avoid the m2m "relationships" they are badly designed, and do not actually buy you anything
09:25 karjala_ Ok, but they look good in templates
09:25 karjala_ where you want as less code as possible#
09:26 karjala_ will the m2m relationships be replaced with something else in the future?
09:26 karjala_ (other than multi-hop description language)
09:26 ribasushi it's m2m helper, it's not relationships, stop calling them that ;)
09:26 karjala_ ok
09:26 ribasushi this is what happens behind the scenes for you:
09:27 ribasushi https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/lib/DBIx/Class/Relationship/ManyToMany.pm#L63-70
09:27 ribasushi calls search_related twice in a row with *really* questionable handling of any arguments that you'd pass
09:28 ribasushi it is not part of the result_source metadata, it is not part of SQL::Translator's deploy() parse, it's just methods thrown into your class, nothing else
09:28 ribasushi ( methods that you could have written yourself, in a more robust manner )
09:30 ribasushi anyway - all of this is speculation and is at least 2 years out
09:30 ribasushi the original answer to your question "will m2m helpers as they exist today in DBIC be treated as relationships" is "no"
09:32 karjala_ ok! :-)
09:45 karjala_ And the reason for that is that coding that would be too complicated?
09:45 ribasushi I am not sure I understand your question
09:46 ribasushi karjala_: rephrase?
09:47 karjala_ Ok, I was just wondering why this "convenience" (of being able to state the m2m in prefetch) will be avoided, even in the future. And I guessed (with a question) whether it's because it's too complicated to code correctly and robustly?
09:47 karjala_ a
09:47 karjala_ you say "as they exist today", sorry, didn't see that.
09:48 karjala_ so, in a future form, m2m helpers might be treated as relationships, right?
09:48 ribasushi no
09:49 ribasushi m2m helpers will be retired, and in their place a different declaration will be added, which is based on a more flexible system, tied with the "parameterized joins" stuff
09:49 karjala_ a cool
09:49 ribasushi the "write portion" of m2m helpers must go, it is unpredictable and thus dangerous
09:50 ribasushi so it is not a matter "complicated to code correctly"
09:50 ribasushi but rather the existing design is broken, and doing anything furthering it is a no-go
09:51 ribasushi and replacing it, while keeping maximum backcompat is not a simple undertaking, and moreover the lower level pieces that are required do not yet exist
09:51 ribasushi does this answer your question better?
09:51 karjala_ so instead of $row->consumers (an m2m helper), I should (for now) replace that with: $row->intermediates->search_related('consumer') ?
09:53 ribasushi calling $row->consumers in a template is fine ( though it usually isn't what you want, as you can get repeated consumer's, if your linker table can have multiple parameterised links )
09:53 ribasushi but in backend code - yes, avoid using them
09:54 ribasushi and to reiterate - in both cases be aware that $row->intermediates->search_related('consumer')  might return duplicates depending on what your schema/data looks like
09:56 karjala_ it answers almost 100% of my question. I still wonder if in the far future you might consider a totally new system for m2m helpers/whatever, incompatible with the old one if needed, and whether you'd consider treating that like a relationship. And if not, why not?
09:56 ribasushi it is possible, but very unlikley
09:57 ribasushi fundamentally a relationship within DBIC is a table-to-table specification ( in fact it is half a specification, literally a single JOIN )
09:57 ribasushi expanding that to cover more than one ( what I referred to as multi-hop above ) is possible, but tricky to design such that it works just as well as the current relationship system ( retains composability etc )
09:58 ribasushi I am not saying "it can't happen", I am saying "I haven't thought about both due to the limited utility that kind of addition would have and the magnitude of other problems that are way more pressing )
09:58 karjala_ ok that's fine
11:01 * ashimema has been caught out by M2M a few times
11:01 ashimema and made the decision to just remove all of them from his schema's a while ago and force himself to use proper relations throughout instead
11:02 * ashimema would still be interested to get riba's hints and tips relating to the other day.. but is still in no rush if he's busy :)
11:43 ribasushi ashimema: haven't forgotten, but still very busy :/
11:44 ribasushi ashimema: if you can highlight me monday before noon, it'd be grand
14:26 ashimema brill.. thanks

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