From 01223745750e9359f88446ce646e36563b5baabe Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Mon, 1 Jun 2009 01:28:07 +0000 Subject: Add defining models chapter. --- docs/tutorials/bfgwiki2/definingmodels.rst | 63 ++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 docs/tutorials/bfgwiki2/definingmodels.rst (limited to 'docs/tutorials/bfgwiki2/definingmodels.rst') diff --git a/docs/tutorials/bfgwiki2/definingmodels.rst b/docs/tutorials/bfgwiki2/definingmodels.rst new file mode 100644 index 000000000..334f87890 --- /dev/null +++ b/docs/tutorials/bfgwiki2/definingmodels.rst @@ -0,0 +1,63 @@ +=============== +Defining Models +=============== + +The first change we'll make to our bone-stock paster-generated +application will be to define a:term:`model` constructor representing +a wiki page. We'll do this inside our ``models.py`` file. + +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 ``Model`` class from +the generated ``models.py`` file. The ``Model`` 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. The +code generated by our ``routesalchemy`` paster template does not use +declarative SQLAlchemy syntax, so we'll need to chage various things to +begin to use declarative syntax. + +Our ``Page`` class will have a class level attributes +``__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: + +.. literalinclude:: src/models/tutorial/models.py + :linenos: + :language: python + -- cgit v1.2.3