> Read the latest version of this page
Edit me on GitHub

Defining the Domain Model

The first change we’ll make to our stock paster-generated application will be to define a domain model constructor representing a wiki page. We’ll do this inside our models.py file.

The source code for this tutorial stage can be browsed at http://github.com/Pylons/pyramid/tree/1.0-branch/docs/tutorials/wiki2/src/models/.

Making Edits to models.py

Note

There is nothing automagically special about the filename models.py. A project may have many models throughout its codebase in arbitrarily-named files. Files implementing models often have model in their filenames (or they may live in a Python subpackage of your application package named models) , but this is only by convention.

The first thing we want to do is remove the stock MyModel class from the generated models.py file. The MyModel class is only a sample and we’re not going to use it.

Then, we’ll add a Page class. Because this is a SQLAlchemy application, this class should inherit from an instance of sqlalchemy.ext.declarative.declarative_base. Declarative SQLAlchemy models are easier to use than directly-mapped ones.

Our Page class will have a class level attribute __tablename__ which equals the string pages. This means that SQLAlchemy will store our wiki data in a SQL table named pages. Our Page class will also have class-level attributes named id, pagename and data (all instances of sqlalchemy.Column). These will map to columns in the pages table. The id attribute will be the primary key in the table. The name attribute will be a text attribute, each value of which needs to be unique within the column. The data attribute is a text attribute that will hold the body of each page.

We’ll also remove our populate function. We’ll inline the populate step into initialize_sql, changing our initialize_sql function to add a FrontPage object to our database at startup time. We’re also going to use slightly different binding syntax. It will will otherwise largely be the same as the initialize_sql in the paster-generated models.py.

Our DBSession assignment stays the same as the original generated models.py.

Looking at the Result of Our Edits to models.py

The result of all of our edits to models.py will end up looking something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import transaction

from sqlalchemy import Column
from sqlalchemy import Integer
from sqlalchemy import Text

from sqlalchemy.exc import IntegrityError
from sqlalchemy.ext.declarative import declarative_base

from sqlalchemy.orm import scoped_session
from sqlalchemy.orm import sessionmaker

from zope.sqlalchemy import ZopeTransactionExtension

DBSession = scoped_session(sessionmaker(
                             extension=ZopeTransactionExtension()))
Base = declarative_base()

class Page(Base):
    """ The SQLAlchemy declarative model class for a Page object. """
    __tablename__ = 'pages'
    id = Column(Integer, primary_key=True)
    name = Column(Text, unique=True)
    data = Column(Text)

    def __init__(self, name, data):
       self.name = name
       self.data = data

def initialize_sql(engine):
    DBSession.configure(bind=engine)
    Base.metadata.bind = engine
    Base.metadata.create_all(engine)
    try:
        session = DBSession()
        page = Page('FrontPage', 'initial data')
        session.add(page)
        transaction.commit()
    except IntegrityError:
        # already created
        pass

Viewing the Application in a Browser

We can’t. At this point, our system is in a “non-runnable” state; we’ll need to change view-related files in the next chapter to be able to start the application successfully. If you try to start the application, you’ll wind up with a Python traceback on your console that ends with this exception:

ImportError: cannot import name MyModel

This will also happen if you attempt to run the tests.

Table Of Contents

Previous topic

Basic Layout

Next topic

Defining Views