Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>No, you do not need to create a separate app for each model. You should create an application for each distinct set of functionality in your project. Since you're just learning, you should create one application (with the name of your project) and use that to learn. </p> <p>As for the models, they are just a representation layer of the tables in your db that makes it easy and handles a lot of the heavy lifting associated with interacting with your db. So in your case you would create a model for each table in your existing db: Widget, Creator (you may want to consider making this a foreign key link to your User table), Customer, Order. </p> <p>The way you return specific data is through your views. So for example to get all the data for a specific widget using the url in your example, the url /widget/1234 would point to a function on your views.py page where you would query your db for the information you need, and send it to your template. In your example the query would look something like:</p> <pre><code>widget = Widget.objects.get(id=1234) </code></pre> <p>Note that since you have an existing database you will have to override Django's default db naming conventions. You can read more about how to do that here: <a href="https://docs.djangoproject.com/en/dev/topics/db/models/" rel="nofollow">https://docs.djangoproject.com/en/dev/topics/db/models/</a></p> <p>However the best advice I can give you would be to put your own project/app aside for a couple of days and go through the official Django tutorial and documentation. Especially when you're first learning, its incredibly well documented and easy to learn:</p> <p><a href="https://docs.djangoproject.com/en/dev/" rel="nofollow">https://docs.djangoproject.com/en/dev/</a></p>
    singulars
    1. This table or related slice is empty.
    1. PODjango, Models, and Apps
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USrolling stone
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODjango, Models, and Apps
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI have my models defined, complete with ForeignKeys etc, thanks to the "manage.py inspectdb" command, and also had to add several db_column and related_name parameters, but all good. So, I have /widget/1234 pulling data from multiple tables and outputting with a template. I guess the thing I'm not sure about is when functionality should be moved to a new App? ie, if I have pages that are purely "Widget" oriented in my app so far (widget search, widget detail views), and I want pages that are "Customer" and "Order" oriented, should those stay in the same app or make a new one? Same models.
      singulars
      1. PO
      1. USRaolin
    2. COAnd thanks for the answer, btw!
      singulars
      1. PO
      1. USRaolin
    3. COI see, sounds like you're a lot farther along than I thought. The criteria for when you should create a new app doesn't depend on the type of page, since that can easily be handled by the view for that page. Rather, according to the docs, an app is "a Web application that does something -- e.g., a Weblog system, a database of public records or a simple poll app." So if you have a really simple application, which it seems like you may have, you really only need one app.
      singulars
      1. PO
      1. USrolling stone
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload