18.10.2016 Views

Drupal 7 Module Development

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Working with Content<br />

}<br />

catch (Exception $e) {<br />

$transaction->rollback();<br />

watchdog_exception('artwork', $e, NULL, WATCHDOG_ERROR);<br />

return FALSE;<br />

}<br />

Most of the save routine is self-explanatory, and much of it is specific to the properties<br />

we've declared on our entity. A few parts bear further discussion, however.<br />

We're wrapping the entire process in a PHP try-catch block. That's because the<br />

save process could be arbitrarily complex, involving a number of queries, any of<br />

which could, potentially, break. We therefore start a database transaction with the<br />

db_transaction() function. Transactions allow multiple database queries to either<br />

all succeed or all fail together. Any queries that run, from anywhere, between the<br />

db_transaction() call and when the $transaction variable goes out of scope at<br />

the end of the function will be part of that transaction.<br />

If any queries, anywhere, fail, the database will throw an Exception. (There are<br />

other reasons an Exception could be thrown, too, but that is the most common.)<br />

In that case, we roll back the entire transaction with the rollback() method. Any<br />

queries that had already run get undone, and the entire save process effectively does<br />

not happen. That keeps us from ending up with a half-saved artwork, which requires<br />

manually editing the database to clean up. We also log the exception using a special<br />

utility function that decodes useful information from the exception for us.<br />

Note that transactions are not available if using MySQL's<br />

MyISAM database tables. In that case code will still function but<br />

any attempt to roll back a transaction will be ignored and the<br />

database will still be left in a potentially unstable state. For that<br />

reason, when running on MySQL <strong>Drupal</strong> defaults to InnoDB<br />

tables, which support transactions.<br />

Once we're done saving the artwork, we also call db_ignore_slave(). If we're<br />

running a high-traffic site then we may have both a master database and one or more<br />

slave databases configured, something <strong>Drupal</strong> supports natively. However, there<br />

may be a latency before our artwork gets propagated from the master server to the<br />

slave server. We therefore tell <strong>Drupal</strong> that, for the current user only, it should skip<br />

the slave server for a few minutes so that the user that submitted the artwork will<br />

see it immediately, even if there is a brief delay for other users.<br />

[ 174 ]

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!