Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-10-11

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

All times shown according to UTC.

Time Nick Message
02:47 ilbot2 joined #askriba
02:47 Topic for #askriba is now Where random Perl5-related questions get definitive answers. Conversation log: https://is.gd/askriba_irclog (searchable). Currently no preset business hours due to low demand: just highlight my name and I'll answer ASAP \o/
02:49 haarg joined #askriba
04:04 dboehmer_ joined #askriba
07:18 karjala_ joined #askriba
08:12 Relequestual joined #askriba
11:21 Relequestual joined #askriba
11:56 karjala_ I had a discussion on #dbix-class 43 minutes ago
11:56 karjala_ I would be interested in hearing your opinion on this...
11:57 ribasushi I saw it
11:57 karjala_ (especially whether you think the demand is fair, and whether dbic or its clone could ever allow replacing SQL::Abstract with another class)
11:57 karjala_ or any other comments you may have
11:58 ribasushi your thinking is mistaken: search([]) can not differ from search({})
11:58 ribasushi apart from that - yes, you can add your own SQLA subclass
11:58 karjala_ i already can do that?
11:58 karjala_ o
11:58 karjala_ ok
11:59 ribasushi ( though I wouldn't recommend it in your case: as you will potentially break libraries which assume [] is a noop )
11:59 ribasushi ( looking for docline, sec... )
12:00 karjala_ so: would you recommend overriding search_rs in ResultSet.pm ?
12:01 karjala_ ...to handle the case or first parameter = [] ?
12:01 karjala_ of*
12:02 ribasushi I recommend giving up on trying to "fix" this - it is not nearly as big of a problem as you think it is
12:02 karjala_ ok
12:03 karjala_ But I had a bug the other day - I got 40k search results on the webpage (the whole table) on my website because a sub-search found 0 results
12:03 karjala_ That was unexpected, and it required a few extra lines to fix
12:03 karjala_ but it's ok
12:04 karjala_ once you know it it's not that horrible
12:05 ribasushi https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/t/sqlmaker/limit_dialects/custom.t#L25-26
12:05 ribasushi karjala_: it apparently isn't documented, but something like the above
12:05 ribasushi again - I advise you to not go down this path: this is not an problem worth trying to fix
12:05 karjala_ ok thanks
12:22 karjala_ The idea behind you saying that search([]) should be a noop, is to give the expected behaviour to someone who is thinking in terms of SQL? (eg join(' OR ', @empty_array) )
12:25 ribasushi throughout its entire design SQL::Abstract treats [] and {} identically
12:26 ribasushi the only exception is an explicit IN <emptyset> operator
12:26 ribasushi "fixing" this requires rethinking of each and every composition site within the SQLA grammar, to see if it actually makes sense
12:27 ribasushi in other words - you are looking at it from the "but I didn't mean that" pov in a very specific singular case
12:27 ribasushi whereas the correct way to evaluate this is from the pov of [] being a basic atomic building block within the entire DSL
12:28 ribasushi because I am very used to this DSL - I don't even need to think much to say "of course they are equivalent"
12:29 karjala_ ok thanks
12:42 Relequestual joined #askriba
15:25 karjala_ joined #askriba
18:08 karjala_ joined #askriba
19:23 karjala_ joined #askriba

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