Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-09-04

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

All times shown according to UTC.

Time Nick Message
01:50 karjala_ joined #askriba
04:04 dboehmer_ joined #askriba
08:00 Relequestual joined #askriba
08:19 karjala_ joined #askriba
10:01 ashimema :confused:
10:02 ashimema If I fetch a result, then update some of the fields using ->update(\%cols)
10:02 ashimema using a ternary to output one of the un-updated fields seems to get the wrong value in the check
10:02 * ashimema prepares a mini paste
10:05 ashimema http://paste.debian.net/984348/
10:05 ashimema @ribasushi anything obvious in my logic for that ternary there?
10:06 ashimema the two lines with appended comments with their differing results is whats confusing me.
10:09 ribasushi reading...
10:10 ashimema thanks
10:10 ashimema I bet there's something really obviously flawed in my logic
10:10 ribasushi ah right of course
10:10 ribasushi there is, sec, writing something to illustrate it
10:11 ashimema hugs :)
10:13 ribasushi beh can't seem to correctly reproduce it for you
10:14 ribasushi but basically you want to throw in extra parens ( unless I am misreading )
10:14 ribasushi ( sent => defined ..... ->false ), restofhash
10:15 ashimema er..
10:16 * ashimema is re-reading his own code now to work out where an extra set of parens should go
10:16 ribasushi line 37
10:17 ashimema yeah..
10:17 ashimema but around what..
10:17 ashimema oh.. the whole line
10:17 ashimema (excluding the comments of course
10:18 ribasushi of course
10:18 ribasushi let me know if this works, because I am a bit stumped I can't recreate it locally
10:18 ashimema afraid that still fails for me
10:19 ribasushi right, so I am full of shit ;)
10:19 ribasushi what is the actual failure, I think you are misdiagnosing things
10:19 ribasushi $Data::Dumper::maxdepth = 2; Dwarn $output;  <---- to be sure the failure is where you think it is
10:19 ashimema so.. the field can either be a timestamp or null in the database
10:20 ashimema in this case it's a null and doesn't get updated at all so should remain null
10:21 ashimema the actually error I get is that the call on sent->iso8601 is failing because sent is an 'unblessed reference'
10:21 ashimema ah..
10:21 ribasushi unblessed reference != undefined
10:21 ashimema but the sent should be undefined as it's null in the database shouldn't it?
10:21 ribasushi you *do* have a value, it's just not an object
10:22 ribasushi ok let's step back
10:22 ribasushi you made a number of assumptions that "this is where my failure is" ( based on comments )
10:22 ashimema :(.. indeed
10:22 ribasushi I strongly recommend that you add *more* dumps/debugs to double check your comments
10:22 ribasushi before we go further
10:23 ribasushi given the last piece of info you gave ( the error ) I'd do
10:23 ribasushi $Data::Dumper::maxdepth = 2; Dwarn [ $system_messageResult->sent ]
10:24 ribasushi to make absolutely sure that I will get back an actual `[ undef ]`
10:24 ribasushi and not something else unexpected
10:26 ribasushi ashimema: the reason I am leaning strongly in this direction is that the error you cited does not match your assumption
10:26 ribasushi consider the output of this: perl -e 'for ( undef, {} ) { eval { $_->bar }; warn $@ }'
10:27 ashimema ok
10:27 ashimema well if I Dwarn as suggested the result is `[ undef ]`
10:28 ribasushi good!
10:28 ashimema `$Data::Dumper::maxdepth = 2; Dwarn [ $system_messageResult->sent ]` that one
10:29 * ashimema should really get  better handle on Devel::Dwarn
10:29 ribasushi ( Maxdepth shou;ld be capitalized btw )
10:29 ribasushi next step would be to:
10:29 ribasushi comment out the line in question
10:30 ribasushi Dwarn( or Ddie) $output after it was defined / ensure the *rest* is the way you want it to be ( there are no stray list-returning cals in there )
10:30 ribasushi start uncommenting bits of the problematic line, until you get to the bottom of it
10:31 ribasushi I do not see the problem from the paste, but this doesn't mean it isn't staring us in the face right there
10:31 ribasushi just will require several iterations to find
10:32 ribasushi ashimema: also you could insert a Dwarn into any callchain ( it is designed this way )
10:33 ashimema ack
10:33 ribasushi $system_messageResult->sent->iso8601 can be replaced with Dwarn($system_messageResult->sent)->iso8601 and shoulw continue working as is
10:33 ashimema you are totally right..
10:33 ashimema it's not the like I thought was failing at all
10:33 ribasushi what was it?
10:33 ashimema it's the previous line.. the 'added' one
10:33 ashimema which is always defined
10:33 ashimema ah...
10:34 ashimema I think i know the problem now
10:34 ribasushi it isn't because you did not retrieve the default ;)
10:34 ashimema I set added to \'CURRENT_TIMESTAMP' in the update call
10:34 ashimema but that doesn't get fetched back as an actual timestamp for the datetime inflation does it :(
10:34 ribasushi right, in retrospect I would be able to see this in the paste as well, but your comments (in-code) distracted me
10:35 ashimema and there's not a retrieve_on_update option to go with the retrieve_on_insert
10:35 ashimema aha
10:35 ashimema yeah.. sorry
10:35 ashimema thankyou for walking me through it..
10:35 * ashimema makes a note to properly play with Dwarn more often
10:35 ribasushi hence the suggestion of dumb blind "run smaller and smaller portions until it starts working, and then whatever you touched last, no matter how improbable, is your problem"
10:35 * ashimema racks his brains for the nicest solution for this now he understands the error properly
10:35 ribasushi it forces you to throw any assumption out the window
10:36 ribasushi currently there isn't a nice solution, the closest thing is $system_messageResult->discard_changes after the update( with default) call
10:36 ribasushi ( the method has a shitty name, it is essentially reload_from_storage() )
10:37 ashimema yeah.
10:37 ashimema stupid tihng is.. I'm sure I've been here before!
11:40 haarg joined #askriba
12:22 karjala_ It would be helpful if the manual of DBIC linked to the Helpers module... just like vue.js guide links to all sort of external stuff
12:25 ribasushi karjala_: in theory you are correct - in practice just adding more links without a good reorganisation of the documentation has more down than upsides, as the amount of available reading material is already overwhelming
12:26 ribasushi also not all helpers in the dist are designed sufficiently well to be used "in general", which further complicates how to link to "the good parts"
12:27 karjala_ oh
12:27 karjala_ ok
12:27 ribasushi karjala_: in any case - PRs / patches / whathave you that add things to where you think they should be are good: if anything they will highlight where it is a good idea to add things ( even if your patch is not accepted as-is )
12:29 ribasushi karjala_: there is also https://cdn.rawgit.com/ribasushi/c5d8a29cac40d432fbaf/raw/eb6a8234dd3d4e592189f9fbb13f63ec91b11962/dbic_redocument.htm
12:32 ribasushi ( nobody expressed interest when this was floated as a possible grant )
12:32 karjala_ Pitty
12:33 ribasushi karjala_: errr I mean "nobody said: Oooh I'd like to work on that! Will the TPF fund me?"
12:33 karjala_ yes
13:14 ashimema I'd possibly be interested in that.. but as usual it comes down to priorities and having full time employment means such a thing is likely to be a non-starter for me :(
13:14 * ashimema is alo interested in writing a mojo book.
16:17 karjala_ Is there a way to prefetch two levels deep? Like, if I have tables A->B->C, and I'd like all rows of A inside @a, but I'd like each element of @a to be able to call $a->b->c without issuing new SQL to the database
16:17 karjala_ Is that possible?
16:17 ribasushi certainly
16:17 karjala_ oh
16:17 karjala_ is it in the manual?
16:18 ribasushi should be, looking...
16:18 ribasushi https://metacpan.org/pod/DBIx::Class::ResultSet#PREFETCHING
16:18 karjala_ thanks!
16:19 karjala_ You're absolutely right! I had seen it, but forgotten it.
16:19 karjala_ Thank you!

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