DBIx::Class::Report - generate ad-hoc dbic classes from SQL

Object-Relational Mappers (ORMs) are awesome if you think about your database a collection of objects. They're awful if you think about your database as a database. My primary client right now is ZipRecruiter and my work involves rewriting one of their internal systems to be more flexible. However, it involves tons of reporting. For example, I have this SQL:

  SELECT var.name, ce.event_type, count(*) as total
    FROM tracking_conversion_event ce          JOIN tracking_visitor visitor      ON visitor.tracking_visitor_id      = ce.tracking_visitor_id
    JOIN tracking_version_variant curr ON curr.tracking_version_variant_id = visitor.tracking_version_variant_id
    JOIN tracking_version ver          ON ver.tracking_version_id          = curr.tracking_version_id
    JOIN tracking_variant var          ON var.tracking_variant_id          = curr.tracking_variant_id
   WHERE ver.tracking_id = ?
     AND ver.version     = ?

What you can't see in that SQL is that there are many subtleties in it:

  • That count(*) as total sometimes needs to be replaced by sum(ce.num_events) as total
  • Sometimes I need different sets of fields returned (and that impacts the GROUP BY, too)
  • One of those JOIN statements sometimes needs to be a LEFT JOIN.

Test::More in serious need of review, be afraid!

Do you want Test-* to be released with only one pair of eyes spending any significant time looking at it? No? Me either!

This blog post is a cry out for review. Test-Builder/More/Simple are being seriously reworked. From my perspective as the author of these changes everything looks fine, but that is just one set of eyes.

How can you help?

The git history on master does not lend itself well to review. This is a harder problem to solve. I have been urged by a couple people to rewrite history to make things more clear. I will take the time to make a cleaner branch where history is easier to read. Assuming the new branch works out, and accurately represents history, I will rename master to something else (but always keep it so that people can see it)

Writing XS Like a Pro - PERL_NO_GET_CONTEXT and Static Functions

The perlxs man page recommends to define the PERL_NO_GET_CONTEXT macro before including EXTERN.h, perl.h, and XSUB.h. If this macro is defined, it is assumed that the interpreter context is passed as a parameter to every function. If it's undefined, the context will typically be fetched from thread-local storage when calling the Perl API, which incurs a performance overhead.

Unfortunately, many XS modules still ship without defining PERL_NO_GET_CONTEXT. This is probably due to the fact that for most modules, setting this macro involves additional changes to the XS code. For example, if your XS file has static functions that call into the Perl API, you'll get somewhat cryptic error messages like the following:

The Perl QA Hackathon is still looking for Sponsors

Last year I shared an article about how You Can Help MetaCPAN by Helping the QA Hackathon. A year later, you can still help MetaCPAN by helping the QA Hackathon. As one of the core MetaCPAN developers, I'm planning to attend this event next month. It's still the best chance that I get to sit down and focus on MetaCPAN. MetaCPAN has had the good fortune of having multiple interns working on code since the Hackathon last year and we've made a lot of headway, but there's a lot of heavy lifting which still needs to be done, particularly around how we use Elasticsearch. This is also a good chance for me to be in the same room with folks who work on the toolchain and to get a better feel for how MetaCPAN can help them.

Just to summarize the much more eloquent posts which have preceded mine, Mr. Neil Bowers of White Camel fame shared a very good summary of what goes on at a QA Hackathon.

Data::RenderAsTree might help you replace Data::TreeDumper

It's on CPAN.

My Bad Communication Skills

A couple weeks ago I asked how you "join the conversation" but based on feedback I got, I don't think I communicated well. I think people thought I meant "which blogs do you read?" What I really meant was: when you write a blog entry, where do you post the link so that it's seen by people who are interested in that subject?

So for example, when I write about Perl, I post to blogs.perl.org. I want to blog about other topics too, like web development (JavaScript, CSS, etc); lifehacks; Unix, Linux, shell scripting; general tech / tech business; and database stuff. But when I blog I'd like it to have a chance of being seen. Please let me know your thoughts!

I read comments everywhere. Comment here, or if you prefer, at Blogger.

On Dave Mitchell calling B and B::C a failed experiment

While being blocked from p5p I had to read a new outragious statement by a porter. Who is in reality not a porter like me, just some developer who happens to have no idea what he is talking about.


He struggles with his new super-op OP_SIGNATURE which is at second thought a better idea then the old way to assign lexical values from the call stack at the begin of subroutines, just that it cannot take the stack values, it has to go through an intermediate @_ copy, but that is just an implementation detail which can be optimized away, and goes then on like this:

Dear Lazyblog

Greetings Perl community,

i will give in a week a Talk about Perl - at a German Linux Conference. It will be part technical but in part also giving the people a realistic insight into our community. Slides will be as always on lichtkind.de and slideshare.

So but the reason i tell you this now is because i want to make sure i don't miss the major recent trends. So if you have this cool Perl project / tool / module/ API which is not that often talked about but should - please let me know and post below.

Thank you very much.

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.