sqlite3 zu mysql

Django, Flask, Bottle, WSGI, CGI…
Antworten
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Hi,

ich habe ein kleines Flask-Projekt, wo eine MySQL-DB in production verwendet wird.

Ich würde aber gerne zunächst bei mir (local) auf die Schnelle das Ganze mit sqlite3 entwickeln und testen. Sprich die ganzen Models (Flask-SQLAlchemy) bauen und dann beim deployment die Tabellen in der mysql-DB anlegen, sodass die Models auch greifen.

Macht das so Sinn?

LG
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

Insb. wenn du mit Migrations arbeitest, wird das vmtl. funktionieren. Persönlich würde ich das aber nicht machen. Wenn man in der Entwicklung im Wesentlichen dieselben Komponenten verwendet wie im Staging/derProduktion, kann einem das nach meiner Erfahrung viel Ärger ersparen.

(Schwieriger wird es übrigens, wenn man die Datenbank selbst samt Inhalt wechseln möchte.)
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Danke. Was meinst du mit Migrations?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
sparrow
User
Beiträge: 4165
Registriert: Freitag 17. April 2009, 10:28

Wie übernimmst du denn Änderungen an der Datenabnkstruktur? Dafür gibt es Migrations.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Du kannst zwar prinzipiell lokal sqlite nutzen, du musst dann aber auf einem gemeinsamen Nenner bleiben. Zum einen schränkt dich dass ein, zum anderen besteht das Risiko dass man ganz unbewusst den gemeinsamen Nenner verlässt, schlimmstenfalls hast du dann ein Problem in Production.

Bevor Docker war dass mal trotzdem übliche Vorgehensweise aber inzwischen kannst du ja MySQL über docker ganz leicht lokal laufen lassen. Sqlite zu nutzen ist auch nicht schneller oder einfacher, lohnt sich also nicht und macht aufgrund der Risiken keinen Sinn mehr.
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Danke für die Hinweise. Docker habe ich mir noch gar nicht angeschaut.
Ich dachte man denkt vorher nach und erstellt ein Schema, was möglichst lange tragfähig ist.

Wenn ich beispielsweise Flask-Migrate benutze. Geht das im laufenden Betrieb der App, oder muss die dafür gestoppt werden, weil laut Doku:

Code: Alles auswählen

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_script import Manager
from flask_migrate import Migrate, MigrateCommand

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///app.db'

db = SQLAlchemy(app)
migrate = Migrate(app, db)

manager = Manager(app)
manager.add_command('db', MigrateCommand)

class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(128))

if __name__ == '__main__':
    manager.run()
wird unten manager.run() aufgerufen und nicht app.run().

Also App stoppen -> Models anpassen -> manager laufen -> Anpassungen durchführen -> App wieder laufen lassen?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Ich dachte man denkt vorher nach und erstellt ein Schema, was möglichst lange tragfähig ist.
Man sollte natürlich darüber nachdenken was man tut aber man kann nunmal nicht in die Zukunft schauen. Dinge im Schema zu haben nur für den Fall dass man die vielleicht mal braucht ist auch keine sonderlich gute Idee.
Geht das im laufenden Betrieb der App, oder muss die dafür gestoppt werden[...]
Das hängt von der Datenbank und der Migration ab. Grundsätzlich kann man eigentlich schon Migrationen so umsetzen dass eine Anwendung dabei weiterlaufen kann. Allerdings kann dies unter Umständen ziemlich schwierig werden und eine Kombination aus mehreren Migrationen und Deployments erfordern. Bei MySQL kommt hinzu dass es keine Transaktionen im Zusammenhang mit DDL unterstützt.

Wichtig ist darauf zu achten dass die Migration nicht durch Locks o.ä. die Anwendung für lange Zeit blockiert. Bei älteren Postgres Versionen sollte man z.B. keine Spalte hinzufügen mit deinem Default Wert, da dann die ganze Tabelle neugeschrieben wird. Queries die auf die Tabelle zugreifen blockieren dabei.

Außerdem muss natürlich die aktuell laufende Anwendung auch mit dem Schema nach der Migration klar kommen, ansonsten stürzt dir die laufende Anwendung ab. Sowas wie eine Spalte umbenennen kannst du also nicht (in einem Schritt) machen. Statt dessen musst du mit einer Migration eine neue Spalte hinzufügen, eine neue Version der Anwendung deployen die mit beiden Spalten gleichzeitig klar kommt, mit einer Migration die Daten von der alten Spalte in die neue kopieren, eine neue Version der Anwendung deployen die nur noch die neue Spalte nutzt und schliesslich mit einer weiteren Migration die Spalte entfernen.

Um das hinzubekommen sollte man sich schon mit der Datenbank die man nutzt ziemlich gut auskennen, genau wissen was für SQL eine Migration ausführt und welche Konsequenzen es hat. Wenn du die Dokumentation deiner Datenbank also nicht auswendig kennst, sind Migrationen zu schreiben eine perfekte Gelegenheit genau dass zu ändern.
Antworten