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.

Next, we’ll remove the sqlalchemy.Unicode import and replace it
with sqlalchemy.Text.

1

fromsqlalchemyimportText

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.

As you can see, our Page class has 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, name 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 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: