Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-09-06

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

All times shown according to UTC.

Time Nick Message
04:04 dboehmer_ joined #askriba
04:25 vanstyn_ joined #askriba
05:30 ilbot2 joined #askriba
05:30 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/
05:59 karjala_ joined #askriba
06:55 karjala_ joined #askriba
08:04 Relequestual joined #askriba
10:21 ashimema is it normal for a completely silent failure if you add a non existent relation to a prefetch?
10:22 ashimema typo in a prefetch just had me starting blankly for ages
10:22 ashimema I sort of expect dbic to say something
10:42 ribasushi ashimema: something else is in the mix, vanilla DBIC definitely balks at non-existing relations
10:42 ribasushi ashimema: which version?
10:42 ashimema DBIx-Class-0.082840
10:43 ashimema this is inside a mojolicious controller
10:43 ashimema I was just rather surprised it didn't shout at me ;)
10:43 ribasushi easy to check:
10:44 ashimema what surprised me was that it seemed to fail silently long before I'd expect the db call to fire..
10:45 ashimema sticking warnings in before and after the call to ->find which had the prefetch in it the first warning fired, the second did not
10:45 ribasushi it's not a warning though, it is an exception
10:46 ribasushi rabbit@Ahasver:~/devel/dbic$ git log -1 --oneline --decorate
10:46 ribasushi 72119d6 (HEAD, tag: v0.082840) Release v0.082840
10:46 ribasushi rabbit@Ahasver:~/devel/dbic$ perl -Ilib -It/lib -MDBICTest -e 'my $rs = DBICTest->init_schema->resultset("Artist")->search( {}, { prefetch => "definitely_nonexistent" }); eval { $rs->count }; warn $@; eval { $rs->next }; warn $@'
10:46 ribasushi DBIx::Class::ResultSource::_resolve_join(): No such relationship definitely_nonexistent on Artist at -e line 1
10:46 ribasushi DBIx::Class::ResultSource::_resolve_join(): No such relationship definitely_nonexistent on Artist at -e line 1
10:46 ribasushi ashimema: you need to pastebin some code, there is definitely something else afoot, especially if you are talking about "warnings fired"
10:56 ribasushi ashimema: anything? :)
10:57 ashimema sorry.. had a phone call and this window lost focus
10:57 * ashimema reads back
10:57 ribasushi ashimema: basically... more debug needed... the fact that your second warning doesn't happen ( if I am reading you right ) means that the exception *does* fire ( your program flow changes )
10:58 ribasushi but then something is eating the exception, a stray unchecked eval { ... } perhaps?
10:58 ribasushi you could always Carp::cluck("wtf") at the spot before your find()
10:58 ashimema I think mojo must be swallowing it somewhere
10:58 ribasushi which will enumerate all the eval{}s to the top
10:59 ashimema yeah.. I'll use a cluck instead of my simple warn
10:59 ribasushi but of course figuring out which one is a problem will be... tough
11:00 ashimema the actual bug that resulted it gone now.. I'll investigate why my warnings aren't propagating down to me though..
11:00 ribasushi haarg: I don't recall: does Devel::Confess offer something that makes wading through a stacktrace from a certain point in the program easier? Or cluck() is more or less the best he can get
11:00 ashimema thanks riba.. at least I'm not going mad.. dbic is sensible and does shout at you for being an idiot when your an idiot.. it's that somthing else in my code is hiding that shout ;)
11:01 ribasushi haarg: context: he *seems* to be having an exception-swallowing-eval imposed by something in the mojo stack, giving him ideas how to possibly find it
11:02 haarg if it's being swallowed entirely, Devel::Confess won't really be able to help
11:03 ribasushi I meant does it have some lower-level function that produces easier to eyeball output as opposed to just calling Carp::cluck()
11:05 ribasushi ashimema: I guess I am being dumb: you could load Devel::Confess, and just call the usual warn() - the stacktrace is going to be appropriately decorated, hopefully letting you see extra stuff by twiddling D::C's flags ( like deparse etc )
11:05 ribasushi haarg: sorry for the noise still waking up
11:05 ashimema cheers chaps
11:06 ashimema think i have enough to get me going ;)
11:11 haarg i can think of three things here that could make sense to add to D::C.  a filter to only apply to warn/dies based on package (or package in call stack).  an option to limit the stack trace to stop at a certain package (many times there is lots of wrapping code that adds too much noise).  and an option to issue warnings for all exceptions.
11:13 haarg i'd have to try implementing that though to see how much weight it added.
11:15 ribasushi right, I only pinged you as I half-reasond through: D::C can give better ways to eyeball code, with the source-dumping stuff added, which in turn can make it easier to spot which eval in the stack is the "silencer"
11:15 ribasushi but then didn't click that "... and he can insert a simple warn ( like he already did ) and load D::C to get the effect"
11:16 ribasushi ashimema: I mean this btw, in case you are not aware what does Devel::Confess add:
11:16 ribasushi perl -Ilib -It/lib -MDBICTest -MDevel::Confess=source -e 'DBICTest->init_schema->resultset("Artist")->search( {}, { prefetch => "definitely_nonexistent" })->next'
11:17 ribasushi =sourceNN to turn up the amount of lines for each frame ( as in `grep -C` )
11:18 ribasushi haarg++ # excellent tool is excellent
11:18 ashimema ah.. cool
11:19 * ashimema is still learning all the goodness of proper debugging tools.. still a bit of a perl n00b really.. been writing baby perl for years and only just starting to really sharpen my teeth on harder concepts.
11:19 ashimema think my 'self taught without much time to actually dive deeper than the surface' is really starting to show :(
11:20 * ashimema thanks everyone for their consistent and ongoing patience with my often daft questions.. and that instead of just solving it for me walking me through the solution and how to come to it myself in the future :)
11:21 ribasushi valar dohaeris ;)
12:43 Relequestual joined #askriba
12:55 karjala_ Does DBIC use Moo?
12:56 karjala_ are its result classes made with Moo?
12:56 karjala_ Can I write: has this => that, like in Moo classes?
13:11 ribasushi karjala_: DBIC was designed/written before any of Moo(se) existed, and as such does not provide these "meta"-protocols within its results and resultset classes
13:11 ribasushi you *can* mix them explicitly, but usually this turns out to be problematic for ResultSets ( due to the atypical new() signature ) and problematic for Result classes ( due to them having 2 distinct constructors )
13:12 karjala_ Ok I wont do it then
13:12 ribasushi karjala_: basically: if your coding-standard imposed by a team/employer calls for it - it can be done
13:13 ribasushi but the general recommendation is: do not do it
13:13 ribasushi .oO( frew can probably rant up some stories about Moose/DBIC mixing :D )
13:13 karjala_ I just want to attach an object of class OtherClass to one of my Result's
13:14 karjala_ so that I can repeatedly call ->other and get the same Moo object back
13:14 karjala_ But it's not terribly important. Would just make code 10% prettier
13:15 ribasushi karjala_: https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/FAQ.pod#How-do-I-store-my-own-(non-db)-data-in-my-DBIx::Class-objects?
13:16 ribasushi mk_group_accessors('simple' => @list_of_names); is *kinda* like has [@list_of_names] => ( is => 'rw' )
13:17 karjala_ Oh interesting
13:17 karjala_ I should read the entire documentation with more attention
13:18 ribasushi karjala_: sadly a large portion is outdated / imprecise, so I'd recommend using it as a reference, not as an endorsed book
13:18 ribasushi ( remember my writeup about "redocumentation project" - that's why ;)
13:18 karjala_ ok i see
13:21 haarg i still want to make Moo interact better with DBIC, but it's rather painful.
13:22 haarg my general recommendation would be to not combine them, but since people do anyway i'd rather have it work properly
13:23 karjala_ what does "fetch a formatted column" mean? https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/FAQ.pod#..-fetch-a-formatted-column?
13:24 karjala_ a, like a database column, that you dont want to access as-is from the db, but have some pre-processing applied to it after fetching and before storing?
13:24 karjala_ pre- post-
13:25 ribasushi yes, and that's one of these "outdated advice" things I was talking about
13:25 karjala_ is the method described wrong?
13:25 karjala_ what's the right way?
13:26 karjala_ (I'm interested in complex-data columns that get stored as JSON to a TEXT field)
13:26 ribasushi it assumes that the Result class is the "facade" to your other application
13:26 ribasushi and as such works modifying its API to be both a "proxy" for the RDBMS and have some business logic ( formatting etc )
13:27 ribasushi the Result part of DBIC is not something I'd recommend using this way today - keep the business logic elsewhere, and have it delegate the IO to the Result class
13:31 karjala_ I think I might have understood - did you just suggest that the main app.pl program uses Business::Logic classes (maybe made with Moo) representing objects, which in turn call methods on DBIC-schema classes & objects? Ie that the app's logic should call DBIC-related methods directly?
13:32 karjala_ Ie that the app's logic shouldNT call DBIC-related methods directly?
13:34 ribasushi correct, the Result class hierarchy is pretty badly designed ( unlike ResultSet's which mostly stood the test of time )
13:37 ribasushi karjala_: you *can* get by using DBIx::Class::Core-based result classes, but you will keep running into obstacles like the ones you are asking this morning likely throughout the entire life of the project
13:37 ribasushi I shouldn't have said "obstacles", more like "idiosyncrasies"
13:49 karjala_ ribasushi, so I should add a method on my resultset classes, which do:sub { return map {Busines::Logic::Object->new($row)} $self->all; }
13:49 karjala_ so that I have a way to map a resultset object into an array of business objects?
13:51 karjala_ no, i should "hide" all DBIC queries inside the resultset & result classes... then I won't need to call the above sub from anywhere
13:51 karjala_ ok, sorry for confusing you
14:15 frew I can rant, if need be.
14:43 ilbot2 joined #askriba
14:43 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/
14:49 ilbot2 joined #askriba
14:49 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/

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