Seite 3 von 4

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 15:36
von noisefloor
Hallo,
Ich würde sagen das Django-ORM ist einfacher, aber dafür halt auch nicht so flexibel.
+1

Gruß, noisefloor

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 16:08
von 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?

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 17:06
von noisefloor
Hallo,
meego hat geschrieben: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.

meego hat geschrieben: 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.

meego hat geschrieben: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

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 17:19
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 18:06
von meego
@BlackJack: Okay. Aber was meint eigentlich "unflexibel" in der Praxis?

Re: Warum braucht es SQLAlchemy?

Verfasst: Dienstag 14. Juli 2015, 22:36
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 08:29
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 08:51
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 10:10
von 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?

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 11:21
von BlackJack
Noch ein Link zum Thema Django und nur für Prototypen geeignet: What is the highest traffic website built on top of Django?

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 11:39
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 12:31
von 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...

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 16:45
von 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?

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 16:55
von DasIch
Das Tutorial kürzt nichts ab. Django vergibt vergibt selbst eine Primärschlüssel sofern man nicht selbst einen vergibt.

Re: Warum braucht es SQLAlchemy?

Verfasst: Mittwoch 15. Juli 2015, 21:31
von 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?)

Re: Warum braucht es SQLAlchemy?

Verfasst: Donnerstag 16. Juli 2015, 09:59
von 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'.

Re: Warum braucht es SQLAlchemy?

Verfasst: Donnerstag 16. Juli 2015, 10:32
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Donnerstag 16. Juli 2015, 10:52
von 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']?

Re: Warum braucht es SQLAlchemy?

Verfasst: Donnerstag 16. Juli 2015, 11:13
von 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.

Re: Warum braucht es SQLAlchemy?

Verfasst: Donnerstag 16. Juli 2015, 11:31
von 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.