Migrations are different depending on your DBMS.
Why? Briefly, here are a few reasons :
1. RDBMS or DBMS (Database management system) is a software that
organizes the data in a database thus allowing for easy management,
administration, retrieval and manipulation of data by users or
applications. e.g. Oracle, PostgreSQL, Microsoft SQL Server, MySQL , DB2,
Informix and so forth.
2. Database is typically housed within a RDBMS or DBMS. A database is an
organized set of logically connected data stored and accessed
electronically from a computer system. The information transforms into
helpful knowledge, structured and maintained to fit
user and or application needs. Apart from storing the data itself, a
database also keeps the relationships between data points via database
normalization rules.
3. SQL is the basic query language used to operate all the database
management systems. There are minor syntax changes amongst different DBMS,
but the basic SQL syntax remains largely the same.
There are many types of SQL commands largely divided into DDL, DML, DCL,
TCL, and DQL. Different DBMSs have their own flavor of SQL. For example
T-SQL for Microsoft, PL/SQL for Oracle
There are also many
Django's Object-Relational Mapper (ORM), enables you to interact with your
database, like you would with SQL and without having to really know the
nuances between one DBS and the other. But if you switch from one DBMS to
the next, you will need to generate and run new migrations each time
including configuration data etc and this will be disastrous. You
therefore, want to use the same DBMS throughout your environments and stack.
On Tuesday, December 28, 2021 at 10:55:02 AM UTC-7 Jason wrote:
> Not exactly. Migrations try to be generalized across db types, but that
> doesn't mean that you can be using db-specific features in your models and
> ORM usage. Thats one reason its highly, highly recommended to use the same
> database and version at all layers of your stack.
>
> In other words, if you're using sqlite locally and postgres in deployment,
> you're opening yourself to the high probability of having to figure
> something out and finding out that its due to different features in the
> db.
>
> On Tuesday, December 28, 2021 at 10:42:56 AM UTC-5 [email protected] wrote:
>
>> As far as I know, the migrations are "Python-Code" in themselves, only
>> defining which tables change in what way. Only when they are being
>> applied, this is turned into actual database code.
>>
>> But you can test this easily by creating migrations and look at them. Or
>> use e.g. a postgres docker container, if my memory is wrong.
>>
>> Cheers
>>
>> Lars
>>
>> Am 28.12.21 um 16:02 schrieb Anil Felipe Duggirala:
>> > hello,
>> > I running an app locally using an SQlite database (I have not been able
>> to set up postgresql locally). I am running the same app in Heroku, using
>> Postgresql.
>> > If I run "makemigrations" locally, then push those migrations to Heroku
>> (which is using postgresql), will those migrations be applied correctly by
>> just doing "migrate" on Heroku.
>> > Do the contents of migrations files depend on the database type that is
>> associated to the app when creating the migrations?
>> > thank you,
>> >
>> > Anil F
>> >
>> --
>> punkt.de GmbH
>> Lars Liedtke
>> .infrastructure
>>
>> Kaiserallee 13a
>> 76133 Karlsruhe
>>
>> Tel. +49 721 9109 500 <+49%20721%209109500>
>> https://infrastructure.punkt.de
>> [email protected]
>>
>> AG Mannheim 108285
>> Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/d61f6aa9-30b3-4de4-ada8-2b69bd7468cbn%40googlegroups.com.
