==============================================
 Create another App Table (``mileage_entry``)
==============================================

You won't be surprised to learn the process is basically the same, for
adding the second and subsequent tables.  Go through the New App Table
Wizard as before, giving details for the desired table.

See :doc:`first-table` to revisit all the gory details.

Here are the specs we'll go with for this entry table.  Note that we
*disable* versioning history for this table, since there is "no need"
for it.  If you feel differently, enable it.

* **Table Name** - ``poser_mileage_entry``
* **Model Class** - ``MileageEntry``
* **Model Title** - ``Mileage Entry``
* **Model Title Plural** - ``Mileage Entries``
* **Description** - Represents a "mileage entry" recorded at time of fillup.
* **Versioning** - *disabled*

And for **Columns**:

* ``date`` - date, not nullable
* ``vehicle_uuid`` - FK (see below), not nullable
* ``fillup_gallons`` - numeric(7, 3)
* ``fillup_payment`` - numeric(6, 2)
* ``odometer`` - integer
* ``notes`` - text

Note that we're allowing nulls for the fillup and odometer values.
This is just to keep things practical since in the real world you
might just want to enter what data you have, even if you're doing it
days after the fact and no longer have it all.  But that's a judgment
call and you can design however you want.

One complicating factor for our entry table, as compared to the
vehicle table, is that we want each entry record to reference a
vehicle record.


Referencing another Table via foreign key
-----------------------------------------

It's possible to define a "typical" foreign key column, and even get a
SQLAlchemy ORM "relationship" setup properly within the generated
code.  Really "typical" is the keyword, but thankfully that's what our
little tutorial app calls for here.

(And we're just commenting on the *wizard* here - since it's just
SQLAlchemy under the hood, you can do whatever you want outside of the
wizard.)

When adding the FK column (in 1st step of wizard), the convention is
to name the column with a ``_uuid`` suffix.  For instance here we name
it ``vehicle_uuid`` since that's what we intend to reference.

For data type, choose "UUID+FK" and then choose the appropriate
reference table.  It would be ``vehicle`` except you may recall, we
gave it a custom prefix, so in fact ``poser_vehicle`` is the table
we'll select here.

(Un)Checking the nullable flag works as expected here; for the
tutorial we want it *unchecked* so each mileage entry *requires* a
vehicle reference.

And finally the relationship, this should be named something sane and
simple as it will be used in a Python context.  For instance from a
given mileage entry record, we can directly access its related vehicle
record by way of this relationship.  In this example we just use
``vehicle`` for the relationship name.

Note that for this kind of FK field, the Description you provide will
be set on the relationship instead of the column proper.