Warum braucht es SQLAlchemy?

[noisefloor]

Hallo,

Ich würde sagen das Django-ORM ist einfacher, aber dafür halt auch nicht so flexibel.

+1

Gruß, noisefloor

[meego]

Hallo

Das hier macht etwas Angst:
"wenn man bereits eine Datenbank vorliegen hat die sich mit dem Django-ORM gar nicht oder nur mit Mühe abbilden lässt."

Bzw.: Warum lässt sich nicht jede Dankenbank damit abbilden?

Ich habe auch schon gelesen, web2py und Django seien eigentlich nur für Prototypen geeignet. Aber das Web nimmt alle Meinungen auf. Gibt's denn irgendwelche grossen Seiten die damit gemacht sind?

[noisefloor]

Hallo,

Das hier macht etwas Angst:
"wenn man bereits eine Datenbank vorliegen hat die sich mit dem Django-ORM gar nicht oder nur mit Mühe abbilden lässt."

Bzw.: Warum lässt sich nicht jede Dankenbank damit abbilden?

Hast du falsch verstanden: SA kennt etwas Namens Reflection, mit dem sich bestehenden Datenbanken "automatisch" ins ORM integrieren lassen. Heißt: gilt für Legacy Datenbanken -> hast du nicht -> für die nicht relevant, der Hinweis war allgemene bzgl. SA vs. Django.

Ich habe auch schon gelesen, web2py und Django seien eigentlich nur für Prototypen geeignet.

Bezogen auf Django: Bullshit. web2py habe ich selber noch nie genutzt, kann ich nix zu sagen. Was richtig ist: mit Django kann man sehr schnell eine lauffähigen Prototypen einer Webseite herstellen, denn man dann Schritt für Schritt ausbauen kann.

Aber das Web nimmt alle Meinungen auf. Gibt's denn irgendwelche grossen Seiten die damit gemacht sind?

Anstatt dich auf Webseiten rumzutreiben, die obskure Behauptungen wie die oben aufstellen solltest du vielleicht mal direkt auf die Django Seite gehen.... Auf https://www.djangoproject.com/start/overview/ ganz unten findest du die Antworten...

Gruß, noisefloor

[BlackJack]

@meego: Datenbanken für das Django-ORM müssen bestimmte Bedingungen erfüllen wie beispielsweise einen Integer-Primärschlüssel pro Tabelle (war zumindest so als ich mich das letzte mal damit beschäftigt habe).

Ab wann ist denn eine Seite ”gross”? Ubuntuusers.de baut auf Django auf. Ansonsten listet das Projekt selbst diese Nutzer: Disqus, Instagram, The Guardian, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest, NASA, Open Stack, Rdio.

[meego]

@BlackJack: Okay. Aber was meint eigentlich "unflexibel" in der Praxis?

[BlackJack]

@meego: Was meinst Du jetzt mit unflexibel? Das Django-ORM ist nicht unflexibel sondern SA ist sehr flexibel. Das ist ein Unterschied. Und bedeutet das SA sehr viele Ansatzpunkte vorsieht die Abbildung zu konfigurieren, anzupassen, und zu erweitern.

[meego]

Hi Blackjack: "Ich würde sagen das Django-ORM ist einfacher, aber dafür halt auch nicht so flexibel." war dein Satz.

Ich habe es mittlerweile geschafft, ein paar Daten mit SQLAlchemy in die DB zu schreiben. Es gäbe auch noch Peewee (das etwas ähnlich wie der einfachere ORM Syntax vom Django ORM ausschaut.)

Bleiben also eigentlich noch User-Authentifizierung, Formulare und Adminpanel . Ich komme wohl nicht darum Django parallell mal auszutesten, obwohl ich langsam das Gefühl habe, mich im Kreis zu drehen.

[Sirius3]

@meego: ich würde Dir stark zu einem Gesamtpaket raten. Gerade bei Userauthentication, Sessionmanagement oder CSFR-Schutz kann man, wenn man sich nicht auskennt, viel falsch machen und damit große Sicherheitslücken produzieren. Die Standardeinstellungen von Django sind da schon relativ gut. Über SQL-Injections brauchst Du Dir keine Sorgen machen, solange Du irgendein ORM benutzt. Javascript- bzw. allgemein HTML-Injection-Lücken stopft man relativ bequem mit irgendeinem Templating-System, wobei man unbedingt die Sicherheitshinweise lesen sollte.
Natürlich gibt es für die kleinen Frameworks für alles Zusatzmodule, bevor Du also anfängst, Dir selbst was zu basteln (wie bei der Nutzerverwaltung), schau Dich erst mal um und mach Dich schlau.

[meego]

Okay, das ist wieder ein gutes Argumet. Ein Sicherheitsrisiko will ich nicht werden. Ich werde es mir installieren.

Übrigens. Bei jeder neuen Virtualenvironment dieselbe Fehlermeldung:

Code: Alles auswählen

You are using pip version 6.0.8, however version 7.1.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Aber bei meinem lokalen Python ist es uptodate. Ich kanns zwar über den Befehl upgraden, aber warum berücksichtigt virutalenv nicht einfach mein Ubuntu Systempython PIP?

[BlackJack]

Noch ein Link zum Thema Django und nur für Prototypen geeignet: What is the highest traffic website built on top of Django?

[meego]

Ja, ich glaube ich habe den Kommentar damals auf web2py gelesen. In der Entwicklergooglegroup. Allerdings sprechen die Nutzerzahlen für mich als Newbie sowieso für Django.

[jerch]

Django ist defacto das einzige umfangreichere Webframework in Python, was einen nennenswerten Impact im Sinne von Bekanntheit und Anzahl der betriebenen Webseiten hat. Als Rails aufkam, schossen auch in Python diese Frameworks wie Pilze aus dem Boden. Komischerweise hat sich ausgerechnet Django etablieren können, obwohl es von der Community zu Anfang als unelegant, unpythonisch, schwerfällig, reinventing the square wheel etc. eingeschätzt wurde. Der ORM und das Templatesystem standen lange Zeit unter Beschuss, den Corelibs wurde nachgesagt, den halben Standardlib-Stack nachzubauen.
Die Stärken bei Django waren von Anfang das Gesamtkonzept, welches auf ein gutes Zusammenspiel der Einzelteile ausgerichtet war, und das frei Haus gelieferte Adminfrontend. Auf letzteres waren selbst Rails-Leute lange Zeit neidisch, weil sie nichts vergleichbares hatten.

So genug OT...

[meego]

Im Djangogirls-Tutorial wird unter Kapitel 10 kein Primärschlussel für die Tabelle vergeben. Ist das bei Django so üblich oder eine Tutorialabkürzung?

[DasIch]

Das Tutorial kürzt nichts ab. Django vergibt vergibt selbst eine Primärschlüssel sofern man nicht selbst einen vergibt.

[meego]

Also hat sich Django seit der Skepsis denn verbessert?

Ich habe einmal ein paar Tabellen in models.py definiert:

Code: Alles auswählen

from django.db import models
from django.utils import timezone

# Create your models here.
class Member(models.Model):
	__tablename__ = 'member'
	#Columns for the table user
	street = models.CharField(max_length=80)
	plz = models.CharField(max_length=40)
	city = models.CharField(max_length=150)
	selfdescription = models.TextField()
	verified = BooleanField()
	created = models.DateTimeField(auto_now_add=True)
	deleted = models.DateTimeField()
	countries = models.ForeignKey('countries')

class Messages(models.Model):
	__tablename__ = 'messages'
	timestamp = models.DateTimeField(auto_now_add=True)
	receiver = models.ForeignKey('auth.User')
	sender = models.ForeignKey('auth.User')
	read = BooleanField()
	subject = models.CharField(max_length=150)
	textbody = models.TextField()

class Countries(models.Model):
	__tablename__ = 'countries'
	iso_code = models.CharField(max_length=3)
	name = models.CharField(max_length=100)

class Remote_Source_Members(models.Model):
	__tablename__ = 'remote_source_members'
	remote_source_id = models.CharField(max_length=200)
	remote_source = models.CharField(max_length=100)
	our_member_id = models.ForeignKey('auth.User')

Die Bezeichnung der Tabelle (__tablename__) mag vom Tutorial her gesehen überflüssig sein?
Und die Nutzertabelle Members, bzw deren Spalten sollten wohl irgendwie, an diejenige angefügt werden, die Django bereitstellt.
Dann habe ich noch eine vierte Tabelle für Facebooklogins (aber vielleicht gibt es in Django einen anderen/einfacheren Weg?)

[meego]

Code: Alles auswählen

python manage.py makemigrations portal
SystemCheckError: System check identified some issues:

ERRORS:
portal.Member.countries: (fields.E300) Field defines a relation with model 'countries', which is either not installed, or is abstract.
portal.Messages.receiver: (fields.E304) Reverse accessor for 'Messages.receiver' clashes with reverse accessor for 'Messages.sender'.
	HINT: Add or change a related_name argument to the definition for 'Messages.receiver' or 'Messages.sender'.
portal.Messages.sender: (fields.E304) Reverse accessor for 'Messages.sender' clashes with reverse accessor for 'Messages.receiver'.
	HINT: Add or change a related_name argument to the definition for 'Messages.sender' or 'Messages.receiver'.

[Sirius3]

@meego: willst Du uns nur mitteilen, dass Deine Model-Definitionen Fehler produzieren, oder dass Du wissen willst, warum sie Fehler produzieren? Erster Fehler: Du mußt den Klassennamen, nicht den Tabellennamen angeben. Andere Fehler: Lösung steht ja schon dabei.

[meego]

Sirius. Der Hint zum zweiten Fehler bleibt mir unverständlich, die Beziehung [sender = models.ForeignKey('auth.User')] zur Django-Usertabelle habe ich aus dem Tutorial.

Also benötige ich gar keinen Tabellennamen [z.B. __tablename__ = 'countries']?

[BlackJack]

@meego: *Eine* Beziehung zu `auth.User` ist ja auch kein Problem, aber bei *zwei* führt das halt zu *zwei* Rückverweisen mit dem *gleichen* generierten Namen. An der Stelle muss man bei mindestens einer Beziehung manuell einen Namen für den Rückverweis geben. Am besten aber beiden, weil der automatisch generierte nicht wirklich gut die Beziehung ausdrückt. Oder man gibt an das gar keine Rückrichtung existieren soll, das geht natürlich auch.

Es geht nicht um `__tablename__` sondern darum das beim Fremdschlüssel nicht der Tabellenname sondern der Klassenname angegeben wird. Du hast ja auch `auth.User` geschrieben, also den Klassennamen und nicht den Namen der Tabelle in der die einzelnen Benutzer gespeichert werden.

[DasIch]

Eine Tabellenname wird von Django selbstständig generiert. Solange man keine bestimmten Anforderungen an Tabellennamen hat, z.B. weil man mit einem existierenden Schema zu tun hat muss man __tablename__ nicht nutzen. Das sollte aber auch offensichtlich sein sofern man sich an das Tutorial hält und sich nicht noch irgendwas hinzu fantasiert.