In ASP.NET there is entity framework or something called "database first," where entities are generated from an existing database. Is there something similar for Django?
I usually work with a pre-existing database that I need to create a backend (and subsequently a front end) for. Some of these relational databases have many tables and relations so manually writing models isn't a good idea. I've scoured Google for solutions but have come up relatively empty handed.
You can use the information on this link.
python manage.py inspectdb > models.py
https://docs.djangoproject.com/en/3.0/howto/legacy-databases/
It depends on your database, but I've worked with it and is good.
The default in Django is a Code First-type approach where the Django framework engine creates a Db for you based on your models and uses migrations to update the Db with model changes (like Code First).
https://docs.djangoproject.com/en/1.11/intro/tutorial02/
What you're describing sounds like a Database First approach in the .Net world.
Integrating Django with a legacy database:
https://docs.djangoproject.com/en/1.11/howto/legacy-databases/
Related
I am building an app in Django and it uses a live/in-use database.
Basically since the apps development the SQL Database has undergone some structure changes and it is causing issues with Django, Django will try to apply migrations to the database that already exist. For example:
In the Django app I marked the email column as unique which was fine based on the development database. However the main database now always has a table change that marks the email column as unique. Django is fighting this unique key with the one that already exists.
So is it possible to clear all Django migrations and have it make migrations again compared to the more up to date SQL database structure?
If your models are very out of sync with your database, the easiest option is probably to rebuild your models from scratch using inspectdb.
If your models are pretty close to the database already, the first step is to make sure that your models match the database exactly. You can use sqldiff from django-extensions for this.
Once your Django models match your database, follow this answer to re-create migrations based on the existing database schema.
Every Django tutorial/book I've seen approaches Django projects from what I am going to characterize as an ad-hoc database design method. A project ends-up being a bunch of little apps, each with it's own models, view, etc.
I am trying to locate a resource that covers how to structure a Django project when you do, in fact, start with a traditional DB design process.
For example, let's say that this is the starting point:
And a document describing it:
LEAD Database Guide
How does one approach this so that the various Django apps access a single "global" (bad word) db model that covers the entire schema rather than a bunch of models spread across a bunch of apps?
Are there any resources (books, pdf's, tutorials) that cover this approach rather than the piece-meal approach most commonly seen?
A corollary to this question might be: Is there a, perhaps automated, way to go from an SQL (or MySQL Workbench) schema definition to the equivalent Django ORM?
You can use the inspectdb command to generate models.py from database:
http://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb
Then, you can treat the models as a single app, and add more features/tables into new apps in the future.
I have a few databases in MongoDB that I want to create models for dynamically, since there are many databases and I cannot do it manually. Questions:
What should my models.py look like? (Does inspectdb work with mongodb databases or only SQL based dbs?)
Since the database models are created dynamically, how do I code the serializer class to return the dynamic fields?
Thanks in advance.
Django supports an object-relational mapper, that is aimed at traditional relational databases. While there are a number of mongodb packages for Django, none of them support inspectdb to construct your models. Either way, inspectdb is a kludge designed as a one of process to help a one-of migratation away from a legacy system, i.e. you'd build your models.py file once and never run inspectdb again. This is not what you want to do, as you seem to want dynamic models that can be added or altered at runtime.
On the bright side, Django MongoDB Engine has some support for arbitrary embedded models within pre-defined models. But even then they don't seem too supportive of it:
As you can see, generic embedded models add a lot of overhead that bloats up your data records. If you want to use them anyway, here’s how you’d do it...
In summary, try to build your models as best you can to actually match your requirements. If you know nothing about your models ahead of production, then perhaps Django isn't the right solution for you.
I have an existing python application that runs in a console. This application contain features that is currently using sqlite3 as its data storage.
I am now trying to make use of Django as the presentation and it seems that I would need some help from you guys on how to speed up my transition from console to a web enabled user interface.
I understand that web is stateless and the app will be mostly consumed several people.
Most of my data is in dict which I can be able to convert to a JSON. I am seeking for kind advice on what are the things that I need to understand or if any of you guys have encountered this kind of app that you will need to migrate to a web centric presentation.
It has mostly query based functions which have few argumenta/parameters passed but it seems that I will have problem with the database access in python due to that most of my db queries are raw sql.
Thank you guys in advance.
(if there is any existing projects that I can use as a pattern by all means please do help to share with me)
==========
Resolution
Added this into manage.py:
sys.path.insert(0, os.path.join(BASE_DIR, 'app', 'engine'))
Now I can call my 'engine' package classes/scripts.
This is a pretty open-ended question, but I'll address moving your database to Django's models and custom queries.
Data Layer
Before building your app, you can try and use the manage.py command inspectdb to describe your current schema as Django models. It won't write your model layer for you, but can help you get started.
As #joran-beasley mentioned, sqlite will not be suitable as a production database for a multi-client application. Postgres is widely-used in the Django community, but it is hardly your option that supports raw SQL.
It is possible to migrate some data in XML, YAML, or JSON and import them with django's de/serializers or via the loaddata manage.py command. Consider adding custom managers to your models that are the targets of 1-to-1, Foreign Key, or Many-to-Many fields. You can add a custom get_by_natural_key method that can simplify de/serializing data that contains foreign keys, etc.
Queries
Django's QuerySet api is a wonderful wrapper for wrap SQL, but it will have some limitations. Take some time to review it's capabilities and shortcomings to decide if it can help or hinder your needs.
If you want to continue making raw queries, Django can help you with that too as it offers helper queryset methods like raw or extra. You can avoid the model layer entirely using its django.db.connection.cursor class.
I can't speak to much else that will help you in your transition, but you may find that Django's class-based generic views like DetailView, ListView, UpdateView, or DeleteView may be helpful in setting up some of your more basic interfaces on the web.
Is it fine not to define table stucture in models.py...I mean we are using
cursor.execute('some query')
so its okay not to make something like this :
def tblNew(models.Model)
col1 = models.CharField(max_length=2)
Thanks for guidance, Im a newbie in django.
You CAN create database tables directly in postgresql But you'd have to create models.py files later because otherwise you will be missing out on several things. If you have pre-existing database, then you have django-admin.py command to pick them up for you (https://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb)
ORM. It makes alot of things easyer. Writing sql in views? Why would that be good? Because that is what you get if you do not use ORM at all. And while i do have sql in some of my views, it only exists there because django lacks some features like language collation specific sorting. But otherwise writing sql in views hampers readability.
You can't use database migrations. South (http://south.aeracode.org/) is one awesome project that most big django projects use. In fact i think it was most used django project in some apps poll. Django 1.7 will provide the migrations too, but you will need to declare models im models.py for that. What you loose if you do not use database migrations - SANITY. I do not exaggerate here. Keeping track of database changes in development and prelive/live servers is nightmare otherwise.
Also is not using django ORM in some places (not declaring models) kind of strange, while you will definately use django models and ORM elsewhere - or will you stop using django authentication, sessions and site logic also? All those use django ORM...