Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2016-10-15

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

All times shown according to UTC.

Time Nick Message
12:41 dboehmer joined #askriba
12:42 dboehmer so I have this resultset method which needs to fetch other results which are not included in the current search condition. But I need to apply the same search attributes like order to the new results
12:42 ribasushi right
12:42 dboehmer I just recently learned the a fresh resultset by $rs->result_source->resultset
12:42 ribasushi so the central "resolver" is $rs->_resolved_attrs
12:43 ribasushi it is still private because it is too heavy, and in the distant future the entire attribute subsystem should be switched to a lazy evaluator of some sort
12:43 ribasushi but the existing semi-private thing will remain indefinitely, as too many things on cpan/darkpan use it
12:43 ribasushi it will return a *non-shallow-copied* hash of what you want, so make sure not to modify it
12:44 ribasushi one thing that you mentioned is prefetch - it will not be "preserved" because it itself is just sugar - it has no value on its own
12:44 ribasushi dboehmer: the equivalence is listed here: https://metacpan.org/pod/DBIx::Class::ResultSet#prefetch
12:45 ribasushi dboehmer: the actual resolver is here if curious: https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/lib/DBIx/Class/ResultSet.pm#L3514
12:45 ribasushi dboehmer: does this answer your question more or less?
12:47 dboehmer I didn't know about that aspect of 'prefetch' but the POD describes what I had guessed. I think that shouldn't bother me as the subsequent attributes are preserved
12:47 dboehmer I have no problem not to modify the returned hash. will DBIC modify it once i pass it to the new search()?
12:48 ribasushi dboehmer: some more details about prefetch and how it can be customized in this very short (~3 minute) lightning talk: https://www.youtube.com/watch?v=aqUcMFalaek
12:48 ribasushi dboehmer: it shouldn't no, there is a lot of machinery to make sure state does not leak back and forth, like e.g.
12:49 ribasushi https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/t/search/preserve_original_rs.t
12:49 ribasushi and others
12:51 ribasushi dboehmer: you also mentioned something about "cloning" - what do you mean by that?
12:54 dboehmer I expected I should not modify the attributes hash and wondered which way of cloning is neceessary before passing it to the next search. as you explained it's  non-shallow copied but DBIC takes care not to modify it
12:54 dboehmer I won't either
12:55 ribasushi then you are good
12:57 ribasushi dboehmer: I got to detach soon, does the above give you enough to work with for now?
12:57 dboehmer not yet sure where to pass the hashref I got
12:57 ribasushi you don't really "pass" it anywhere as-is
12:57 ribasushi you will have to take the parts of it you want
12:58 ribasushi I mean you *could* do $fresh_rs->search({}, $the_thing_you_got ), but that won't really help you any
12:58 dboehmer ok
12:58 dboehmer might read like a dump question but I was still reading and didn't try ...
12:58 ribasushi you need to look at its contents and take what you are interested in, and pass *that* to the next search(_rs) call
12:59 dboehmer thank you so much. have a good time whatever you do next
12:59 ribasushi cheers &

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