Joins are currently not supported.
This is mostly because SQL::Abstract does not support them,
and I've yet to have the time or impetus to try and dig in to how DBIx::Class::ResultSet does it.
Also,
in many cases a subselect is a better choice.

Another option is to use DBIx::ResultSet's where_sql() to produce the WHERE portion of the SQL while still being able to write the FROM/JOIN portion of the SQL with raw SQL.
For example:

The DBIx::ResultSet::Connector class provides an interface to facilitate robust transaction management. This is done by using DBIx::Connector, which is available via the dbix_connector attribute. Several of DBIx::Connector's methods are made available directly on the DBIx::ResultSet::Connector object.

All methods in DBIx::ResultSet that need a DBI database handle get it via DBIx::Connector's run() method. It is highly recommended that you acquire a solid understanding of how DBIx::Connector works and how to use it properly. Once you have, you'll find that there are many ways in which you can control database pings, transactions, and lost connection handling.

By default the underlying DBIx::Connector object will be set with a connection mode of 'fixup'. This is typically what most people want. In this setup if the connection is disconnected from the database then it will be automatically re-connected and the code that the run block was attempting to execute will be re-executed. This means that in the following:

It is possible that the e-mail would get sent TWICE if the database connection is lost. This is because the lost database connection isn't deteceted until we actually try to do something with the database, in this case an INSERT. So, when under the 'fixup' connection mode one solution is to change the order of your code to first insert the log, then send the e-mail.

Another solution is to use the 'ping' connection mode which will validate that the database connection is healthy before executing the code block. But, this still isn't 100% reliable because a database connection could potentially be lost at any time.