{"id":4793,"date":"2013-05-10T14:34:24","date_gmt":"2013-05-10T22:34:24","guid":{"rendered":"http:\/\/www.chesnok.com\/daily\/?p=4793"},"modified":"2013-05-10T14:35:33","modified_gmt":"2013-05-10T22:35:33","slug":"til-formatting-search_path-and-colorcolumn","status":"publish","type":"post","link":"https:\/\/www.chesnok.com\/daily\/2013\/05\/10\/til-formatting-search_path-and-colorcolumn\/","title":{"rendered":"TIL: Formatting, search_path and colorcolumn"},"content":{"rendered":"

The last six months have involved a lot more writing of code than the previous couple of years.<\/p>\n

I’ve been tweeting little things I learn on a daily basis and thought I’d look back on this week.<\/p>\n

format()<\/h1>\n

A reocurring problem with report writing is getting numbers formatted properly for the occassion. I discovered ‘format’ in Python this week:<\/p>\n

print \"{0:.2f}%\".format(float(1)\/3 * 100)\r\n<\/code><\/pre>\n
That prints out a float to 2 decimal places. I looked around and Dive Into Python<\/a> has similar syntax, but without the format() function. So, the equivalent would be:<\/p>\n
print \"blah %.2f\" % (float(1) \/ 3 * 100)\r\n<\/code><\/pre>\n
So, why use one over the other? A user on StackOverflow<\/a> suggested that compatibility with 2.5 might drive a person to use ‘%’ over ‘format()’, but otherwise, the poster suggested that format() is the cleaner looking and more flexible choice.<\/p>\n
set search_path = bixie<\/h1>\n
I’m working on a new schema for a project<\/a>. We’re rolling out a prototype quickly, so we’re going to house it in our existing production database for now. To keep things easy to clean up, Laura<\/a> suggested that we put things into a separate schema<\/a>. For managing our database models, I’ve switched to using SQLAlchemy, and also alembic for migrations. This made it super easy to specify that I wanted all the Bixie related tables in their own schema:<\/p>\n
class BixieCrash(DeclarativeBase):                                              \r\n    __table_args__ = {'schema': 'bixie'}                                        \r\n    __tablename__ = 'crashes'\r\n<\/code><\/pre>\n
And that was it.<\/p>\n
Then, to avoid having to add ‘bixie.’ to all the table paths in test queries, I put this command into the tests:<\/p>\n
 cursor.execute(\"\"\" SET search_path TO bixie \"\"\")\r\n<\/code><\/pre>\n
I imagine there are some other ways to handle this. We’re not really using the ORM for anything other than schema loading, so I’ll probably add that to our connection initialization code for the new app. Then developers can write their queries as without any concerns about being in the correct schema.<\/p>\n
And I’ll glow just a little bit about deploying alembic on stage!<\/p>\n