I'm creating a bus booking website using Django. I'm stuck at what the database tables should look like. So far I've created the displayed tables, I'm very poor with databases so please mention foreign keys and primary keys when answering. Also, I'm stuck on how to actually book seats in Django, like what will be the code in the background and what other packages should I use. Thanks.
Table- Route:
Columns - route_id (primary key),
location_from,
location_to,
route_name,
Table - Bus:
Columns - Bus_id(primary key), type_of_bus,
bus_registration,
capacity,
bus_number,
route (foreign key)
Also I'm using the default sqlite database that comes with django. Is it good enough to build this kind of website or do I need to change? This website is just a project and will never go into production phase.
I'd highly recommend writing your database schema in Python classes (as Django models) and then using ./manage.py makemigrations ./manage.py migrate, which will look at your model code and create the corresponding database schema. This portion of the django tutorial could be helpful to you.
The python code corresponding to your example for a route would look something like:
from django.db import models
class Route(models.model):
location_from=models.CharField()
location_to=models.CharField()
route_name=models.CharField()
This is a much easier way to write a database schema, especially if you're not so hot with databases.
If your app will never be in production, SQLite is fine - it's very similar to other database engines for toy projects.
As for what your data model should look like, I think it depends how complex you want to make the app. For a start, I think you could add a Location model, which your Route model should reference. For making reservations, you could look into django booking - I haven't used it but it comes up on django packages when you search 'booking'.
Related
In a Django project, I have a few apps and one model-class will be created in one app's models.py and imported to another apps' models.py. then I run migrate for each app per one schema in Postgres, there is no error reported.
But the issue is the shared model will be migrated to all the schemas because (I assume this is the reason) I imported this model in each app's models.py.
Anyone knows How to avoid or solve this problem. Because I would like keep the model only stay in his original schema.
Or can I delete this model directly from each schema it appears?...without any side effects.
Please help, Thanks!
I found a better answer: Installing PostgreSQL Extension to all schemas.
should see this before.
Accidentally found the solution, just use 'public' schema for the app where models supposed to import to other apps.
Just for someone who experience the same situation.
I spin up a django project. Afterwards, i didn't write models.py but instead I created a database from MySQL command line(independent from django) and created three tables with required columns. Finally i connected my django app with that database successfully. I applied migrations. But now i am confused do i need to write models.py with every field name as in column?
I remember implementing a basic project in which i did write models.py and created database using "python manage.py shell" and then put values using
"from polls.models import Choice, Question"? How do i put data now initially and then using python on some action from UI?
Do i need models.py even for ready made mysql databases?
You do not need to construct models. Some (small) webservers are even completely stateless, and thus do not use a database. But a large part of how Django can help you is based on models.
You can write your own queries, forms, etc. But often by using a ModelForm, Django can for example remove a large amount of boilerplate code. It will make it furthermore less likely that there are mistakes in your code. So although not strictly necessary, the models are usually a keystone in how Django can help you.
You can use the inspectdb [Django-doc] command to inspect the database, and let Django "sketch" the models for you. Usually you will have still some work. Since Django can, for example, not derive that a field is an EmailField, since both a CharField and EmailField look exactly the same at the database side.
You do not need to use inspectdb however. You can construct your own models. If you create your own models, but these exist already at the database side, you might want to set managed = False [Django-doc] in the Meta of your model, to prevent Django from constructing migrations.
We have a Django application that has been in production since Django 1.1. Over the years, we've manually added bells and whistles to the production PostgreSQL db that weren't at the time overtly supported by Django's db automation, especially in the form of custom indexes.
Django's come a long way since 1.1, and now w/ 1.10 I'm pretty sure the migration framework supports all the custom features we've added manually. Is there any automated tool which will compare a database to the models, and generate migrations to bring the models up to date with the db?
This is built into django, you can just run inspectdb
manage.py inspectdb
Introspects the database tables in the database pointed-to by the NAME setting and outputs a Django model module (a models.py file) to standard output. You may choose what tables to inspect by passing their names as arguments.
Use this if you have a legacy database with which you’d like to use Django. The script will inspect the database and create a model for each table within it.
I am having a hard time trying to come up with a reasonable design for my project. I have an existing Postgres database that gets constantly updated from other Python scripts.
The web server built on Django framework will access the Postgres database to update User models only and display blog information for the logged in Users. The blog information is what is being updated overnight by other Python scripts.
Now my question, if I have to syncdb my blog model with existing Postgres database, would that cause any problem?
ex:
models.py
class Blog:
title=...
content=...
author=....
And say my Postgres db called mydb has many tables, one of which is blog table and contains columns for title, content and author.
How would make my model in sync with existing database?
Now lets say I included a new column in my db which is date of entry.
If I simply update my model to :
class Blog:
title=...
content=...
author=....
date of entry=...
will it work.
what are the potential problems here and any simpler solutions for these?
P.S: I have used South in the past. but the situation here is different. I am using db that is read-only from Django's point of view, and no data migration is necessary as of now.
If your database is read-only, you don't have to do syncdb. Use managed=False and the db_table meta option on your model to specify the table name it corresponds to, and likewise for the field column names.
If you haven't already, see the doc on legacy databases for more info.
I am building a web interface for a database at my school. The database will hold our school's versions of academic standards.
When you build a site using django, does it create a clean database? For example, wysiwyg website builders like dreamweaver create ugly html and css code on the backend. I would hate to see a similar degree of auto-generated cruft in my database.
Should I create the database myself and then build a django site to access the database, or go ahead and let django create the database?
Under any simple to moderately complex application, Django will do a fine job creating the database for you. I've yet to run into any issues with what it's made.
I would suggest that you use South to handle your table migrations. And use virtualenv and pip to set up and maintain your Django environment.
You can use the sqlall predicate of manage.py to see the exact SQL that will be executed in order to generate the database.
Obviously django needs database tables for its basic functionality (contrib.apps).
Sure, you don't have to use them, but generally you want to use a least contrib.auth and some other bundled apps:
Each of these applications makes use
of at least one database table,
though, so we need to create the
tables in the database before we can
use them.
I any case you can't and shouldn't compare it to ugly html code generated by dreamweaver or word.
On a more abstract level:
One of key concepts of a web framework (following the mvc pattern) is that you define models which are "translated" (mapped) by the framework into database tables.
A model is the single, definitive
source of data about your data. It
contains the essential fields and
behaviors of the data you’re storing.
Generally, each model maps to a single
database table.
If you want to create the whole database scheme by hand you totally missed the point of using a web framework. In most cases you simply don't need to write sql manually. You define your classes and then you can query your objects using the builtin orm.