I am currently trying a few ways of connecting a postgre sql database that I already have defined using a django model with a front end angular form that I created within the same project. (This a a django project using a little bit angular js)
So basically I have a form which accepts data from a user, and the data needs to be stored in one of the tables of the postgre sql database that I already created.
I was following this but there are many points that are unclear to me. Is there a better way to solve this?
Related
I built a Django project with a few models. Now I created a second server with the same setup. This one is meant to be the deployment server. Databases are separate from the dev-server.
However can you tell me if I can simply copy the databases from the dev server to the deploy or will the Django logic, since I also mean the user models and permissions etc.
The tables which I created myself are no problem to transfer to the new server. However I am wondering If Django gets confused when I also transfer something like the auth_user Model.
Should this work since I also just copied the backend logic as well?
We are migrating our intranet application and have decided to choose the Django framework. We control all of our database via source control and managed scripts, so we do not use the migrate feature to create tables for us. Views and Tables can change, all business logic is held in the database.
I want to make Django API endpoint which is basically select * from my_table_or_view; and Django can return a JSON response with the column names and values. Some database tables have close to 100 columns each so I don't want to write out each and every field name and type just to return a query. What happens if we add another column to the view - will I have to update it in Django as well? What if I change the column type - will my application fail as well?
The frontend is written in VueJS - it makes a request to the API endpoint and should use the columns selected in the frontend, obviously if I remove a column it will break but I don't want to have to add the column in the django framework even if it is not used.
I've read the raw SQL queries section of the docs but i'm not sure where this applies to. Does this logic sit in the views section?
I've tried directing a URL endpoint in URLS.py to a custom class in views.py but not sure this is correct, does this logic need to be in a serializer?
I'd like the simplest method possible, potentially not using models, just raw SQL is fine.
One option for you is to sync your db to django models every time you change your schema and then use it normally, both ORM and raw SQL queries would be possible.
There's a function called inspectdb that does that natively, here is a reference to it
https://docs.djangoproject.com/en/3.1/ref/django-admin/#inspectdb
I'm using Django for backend, but for some reason, I want to use Laravel beside Django and share the database between them. so the same database for Django and Laravel. but the problem is that Django migrations are not equal to Laravel migrations so the database is different from ( for example constraints and indexes and some other options).
Is this going to break backend if I use Django as the primary database and use Laravel as a secondary backend?
If true, how I can use Django and Laravel in the same database?
Your database does not depend on Django or Laravel. It just stores data.
Constraints, triggers, indexes, etc are stored on the database itself, and they are completely independent of your framework. Frameworks just abstract the methods and provide easy methods to manage your database. At the core, they use the same commands which are provided by the database. The names of constraints are irrelevant, you can give whatever names you want, frameworks just provide their own uniform naming pattern, which can be customized by the user. So they can be used on both Django and Laravel or any other framework/programming language. That's the main purpose of having a database, to store data in a structured manner so it can be used by any language/framework
Since you already have migrations in Django, there's no need to create the migrations again in laravel. Just reuse the Django database and make your laravel application to properly handle the data (that part is completely in your control)
I set up a simple django site using django-allauth.
I created some oauth providers in the database.
Everything is fine and working on my laptop now.
I would like to store the created database tables somehow.
Use case: I want to set up a new development environments on a different PC painlessly.
How to store the initial data of django_allauth, so that after checking out the app from git the command manage.py migrate is all I need to have the relevant database tables filled?
Django_allauth already save those data to the database, you will find them in a table *_SocialApp, here is the model code from django_auth source
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.