From 0aed1cdd37fb57663b978d1d8728d5b652b0b092 Mon Sep 17 00:00:00 2001 From: Carlos de la Guardia Date: Tue, 15 Mar 2011 20:35:02 -0400 Subject: Restructured the routes wiki tutorial to make it easier to follow along. Moved the routes tutorial above the traversal tutorial. --- docs/tutorials/wiki2/definingmodels.rst | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) (limited to 'docs/tutorials/wiki2/definingmodels.rst') diff --git a/docs/tutorials/wiki2/definingmodels.rst b/docs/tutorials/wiki2/definingmodels.rst index 09e1f26c3..117442a1c 100644 --- a/docs/tutorials/wiki2/definingmodels.rst +++ b/docs/tutorials/wiki2/definingmodels.rst @@ -31,8 +31,14 @@ application, this class should inherit from an instance of :class:`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 +.. literalinclude:: src/models/tutorial/models.py + :pyobject: Page + :linenos: + :language: python + +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``, ``pagename`` and ``data`` (all instances of :class:`sqlalchemy.Column`). These will map to columns in the ``pages`` @@ -44,15 +50,21 @@ 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 + +.. literalinclude:: src/models/tutorial/models.py + :pyobject: initialize_sql + :linenos: + :language: python + +Here, we're using a slightly different binding syntax. It is +otherwise largely 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`` ---------------------------------------------------- +Looking at the Result of all Our Edits to ``models.py`` +------------------------------------------------------- The result of all of our edits to ``models.py`` will end up looking something like this: -- cgit v1.2.3 From 6ed41a034df40dcc6632432544742ebefe3162ba Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sun, 20 Mar 2011 18:08:58 -0400 Subject: review changes to sqla tutorial --- docs/tutorials/wiki2/definingmodels.rst | 40 ++++++++++++++++----------------- 1 file changed, 19 insertions(+), 21 deletions(-) (limited to 'docs/tutorials/wiki2/definingmodels.rst') diff --git a/docs/tutorials/wiki2/definingmodels.rst b/docs/tutorials/wiki2/definingmodels.rst index 117442a1c..7e8555190 100644 --- a/docs/tutorials/wiki2/definingmodels.rst +++ b/docs/tutorials/wiki2/definingmodels.rst @@ -37,28 +37,27 @@ SQLAlchemy models are easier to use than directly-mapped ones. :language: python 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``, ``pagename`` and ``data`` (all instances -of :class:`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. +``__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 :class:`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. .. literalinclude:: src/models/tutorial/models.py :pyobject: initialize_sql :linenos: :language: python -Here, we're using a slightly different binding syntax. It is -otherwise largely the same as the ``initialize_sql`` in the -paster-generated ``models.py``. +Here, we're using a slightly different binding syntax. It is otherwise +largely the same as the ``initialize_sql`` in the paster-generated +``models.py``. Our DBSession assignment stays the same as the original generated ``models.py``. @@ -76,11 +75,10 @@ something like this: 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: +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: .. code-block:: text -- cgit v1.2.3