Corey Coogan

Python, .Net, C#, ASP.NET MVC, Architecture and Design

  • Subscribe

  • Archives

  • Blog Stats

    • 110,580 hits
  • Meta

Posts Tagged ‘Postgres’

Enter the Python

Posted by coreycoogan on March 1, 2011

My .NET related posts have been pretty sparse lately, mainly because I spend almost no time doing .NET development anymore. That’s right, my platform of choice over the last 11 years is now on the back-burner as it makes room for Python.

There is a lot of hype over Ruby and specifically Ruby on Rails these days. I had been following it and thought that would be the dynamic language and web framework I would cut my teeth on. However, a really great project came along and the requirements included nothing from the MS stack:

  • Python
  • Linux
  • Apache
  • CherryPy or other WSGI server
  • PHP
  • Postgres
  • SQLAlchemy (ORM)
  • Python

    I was very excited to learn something new and have found that I really enjoy working with Python.  It’s dynamic, flexible and easy to work with.  One thing I have really learned to love over static languages is that it doesn’t compile.  That means I just code and go.  That also means I get an interpretter where I can easily spike some code and see how things look and feel.  This makes development much faster for me and I have more confidence than I would with straight TDD.  I can shape my code on the fly and run it with a 2 hits of the ENTER key.

    Speaking of TDD, mocking in Python is an absolute dream.  No more time-consuming and costly setups to mock my objects with Rhino.  Using the Mock module is as easy as can be.   A simple example of stubbing a “firstName” property looks like this:

    person = Mock()
    person.firstName = 'corey'

    If I want to stub a method, it’s as simple as this:

    person.fullName.return_value = 'corey a. coogan'

    There’s much more that can be done, but stubbing alone probably satisfies 80% of my mocking needs.

    On the Web

    Often times when people think of Python they think of Django.  Django looks really terrific and I look forward to having an opportunity to use it.  For now, however, PHP is the answer.  I’ve only worked a little bit with PHP in the past and formed an opinion many years ago.  After working with it for several months, I am still not an advocate for PHP, but it does have it’s strengths. Fortunately, much of the PHP work involves calling JSON services and then using jQuery and JS on the client to do something with it.  There is still a fair amount of PHP tag soup, reminiscant of my classic ASP roots, but I hope to eradicate that one day.


    SQLAlchemy(SA) is to Python what NHibernate is to .NET.  They both allow for domain classes that are completely separated from the mappings, but SA also has some other styles, such as Declarative and SQL Soup, that can come in pretty handy.  The syntax seems pretty clunky at first, but I’m getting used to it.  The documentation is a bit rough, as many of the methods accept  *args,**kwargs, which means you can pass in any number of values and name/value pairs.  The doc tells you what are acceptable arguments, but the examples tend to be a bit scarce.  Look for an upcoming post that has examples for all the things that have tripped me up so far.

    The Times They Are a Changin’

    This blog will continue to focus on technology agnostic goodness, like JavaScript, jQuery, SQL, etc, but .NET content will be far and few between.  I’ll be sharing more of what I’ve learned in Postgres, SQLAlchemy and Python.  Hopefully I don’t lose too many of my .NET readers and hope that my content can help out a new group of people.

    Until next time…


    Posted in Python, SQLAlchemy | Tagged: , , , , | Comments Off on Enter the Python

    How to Move PostgreSql Tables to a Different Schema

    Posted by coreycoogan on December 22, 2010

    Recently an application I’m working on had the need to move a mess of tables from the PG default “Public” schema to a new one, which we’re calling “Selection”. The more recent versions of PG (8.2 as of this writing) have a SET SCHEMA action available on the ALTER TABLE command.

    ALTER TABLE name SET SCHEMA new_schema

    SET SCHEMA is very nice in that it not only moves the tables, but any associated indexes, sequences and constraints.

    From the 8.2 Documentation:

    This form moves the table into another schema. Associated indexes, constraints, and sequences owned by table columns are moved as well.

    This is all fine and good, but if you have more than a couple tables to move, this can be hassle. Here’s how to use PG’s pg_tables System Table to generate the sql for every table in your database. Run this query against the database that has the tables you wish to move. Then simply copy/paste the output into another query window and execute. Don’t forget to make the schema first!

    select 'alter table "' || tablename || '" set schema "Selection";' 
    from pg_tables  
    where schemaname='public';

    Posted in Database | Tagged: , , , , | 1 Comment »