allgemeine probleme bei der erstellung einer web app

[Costi]

vielen dank fuer die detalierte uns hilfreiche antworten

ich werd dan schon jetzt auf postgreSQL umsteigen
und danns gibs hoffentlich keine probleme mehr (-;



.

[EnTeQuAk]

Hallo!

Das geht sogar noch einfacher:

Code: Alles auswählen

try:
    conn = cherrypy.thread_data.connection
except NameError:
    conn = cherrypy.thread_data.connection = sqlite3.connect("...")

cur = conn.cursor()
...

Igittt! Das muss ich ja in jeder meiner Dateien schreiben, damit das anstandslos funktioniert. Da finde ich meine Lösung viel magischer und schicker
(besonders, da sie auf die "Masse" gerechnet weniger Schreibarbeit erfordert)

@Costi: Du kannst auch MySQL benutzen

MfG EnTeQuAk

[gerold]

Hallo EnTeQuAk!

Code: Alles auswählen

try:
    conn = cherrypy.thread_data.connection
except NameError:
    conn = cherrypy.thread_data.connection = sqlite3.connect("...")

Da finde ich meine Lösung viel magischer und schicker

Na ja, so schlimm finde ich das auch wieder nicht. Ich habe meist nur ein Modul von dem aus ich auf die Datenbank zugreife. Und dieses Hauptmodul wird sowiso von den meisten anderen Modulen importiert. Ich denke, damit wäre so eine Funktion (wie unten) kein so schlechter Kompromiss.

Code: Alles auswählen

import cherrypy

def get_conn():
    try:
        conn = cherrypy.thread_data.connection
    except NameError:
        conn = cherrypy.thread_data.connection = sqlite3.connect("...")
    return conn

class Root(object):

    def index(self):
        conn = get_conn()
        cur = conn.cursor()
        ...
    index.exposed = True

...

Aber deine Variante, glaube ich, wird vom CherryPy-Team vorgeschlagen. Aber irgendwie finde ich im Moment nichts darüber im CherryPy-Wiki.

@Costi: Du kannst auch MySQL benutzen

@Costi: Du musst aber nicht unbedingt auf EnTeQuAk hören.

lg
Gerold

[Costi]

ich find gerolds loesung vie interesanter als ``cherrypy.engine.subscribe`` zu benutzen...


trotzdem werde ich mySQL statt posgreSQL benutzen

[EnTeQuAk]

Na ja, so schlimm finde ich das auch wieder nicht. Ich habe meist nur ein Modul von dem aus ich auf die Datenbank zugreife. Und dieses Hauptmodul wird sowiso von den meisten anderen Modulen importiert. Ich denke, damit wäre so eine Funktion (wie unten) kein so schlechter Kompromiss.

Das habe ich auch. Doch ich bin doch eher der Meinung, bereits funktionierende (und vorgeschlagene) Lösungen vorzuziehen, anstatt eine eigene zu basteln. Es sei denn, die vorhandene ist unbenutzbar oder einfach (wirklich) unschick.

Aber deine Variante, glaube ich, wird vom CherryPy-Team vorgeschlagen. Aber irgendwie finde ich im Moment nichts darüber im CherryPy-Wiki.

Im Wiki nicht, aber ich hatte mal einen Post auf der Mailingliste hier, wo Robert entsprechendes geschrieben hatte.

ich find gerolds loesung vie interesanter als ``cherrypy.engine.subscribe`` zu benutzen..

Hast du dafür auch genauere Gründe, wenn man fragen darf?

trotzdem werde ich mySQL statt posgreSQL benutzen

@Gerold:
Nicht traurig sein... du schaffst es noch, ein paar Benutzer zu PostgreSQL zu konvertieren


MfG EnTeQuAk

[apollo13]

trotzdem werde ich mySQL statt posgreSQL benutzen

@Gerold:
Nicht traurig sein... du schaffst es noch, ein paar Benutzer zu PostgreSQL zu konvertieren


MfG EnTeQuAk

Ich bin gerade von MySQL auf postgresSQL umgestiegen
Und mir kommt so schnell kein MySQL mehr auf die Platte, es sei denn es ist nötig

[mitsuhiko]

Und wo ist der connection pool?

[gerold]

Und wo ist der connection pool?

Hallo blackbird!

Diese Frage verstehe ich nicht. 10 Threads -- 10 Connections. Wenn man eine Connection an ``cherrypy.thread_data`` bindet, dann hat man einen Pool von (bei Standardeinstellung) zehn Connections offen. Ich glaube, dass ich damit nicht wirklich falsch liege. Es ist aber auch schon eine Weile her, dass ich mir ein wenig CherryPy-Quellcode angesehen habe.

Oder wie hast du die Frage gemeint?

lg
Gerold

[gerold]

Ich bin gerade von MySQL auf postgresSQL umgestiegen Und mir kommt so schnell kein MySQL mehr auf die Platte, es sei denn es ist nötig

Hallo apollo13!

<Geld auf die Hand blätter...> Und hier die versprochenen 10 Euro. Und das Bier geht auf mich.

mfg
Gerold

[mitsuhiko]

Und wo ist der connection pool?

Hallo blackbird!

Diese Frage verstehe ich nicht. 10 Threads -- 10 Connections. Wenn man eine Connection an ``cherrypy.thread_data`` bindet, dann hat man einen Pool von (bei Standardeinstellung) zehn Connections offen. Ich glaube, dass ich damit nicht wirklich falsch liege. Es ist aber auch schon eine Weile her, dass ich mir ein wenig CherryPy-Quellcode angesehen habe.

Dann hast du einach nur 10 Threads mit 10 Verbindungen. Also MySQL zb öffnet gestorbene Verbindungen nicht automatisch neu. Zumindest wäre mir das neu. Außerdem kannst du dir auf diese weiße nicht zwei Verbindungen in einen Thread holen oder eine Transaktion beenden lassen während der User schon seine Seite bekommen hat.

[gerold]

@EnTeQuAk: Aber deine Variante, glaube ich, wird vom CherryPy-Team vorgeschlagen. Aber irgendwie finde ich im Moment nichts darüber im CherryPy-Wiki.

Hallo EnTeQuAk!!

Jetzt weiß ich wieder, wo ich etwas über Connections in Threads gelesen hatte:

- http://tools.cherrypy.org/wiki/SQLObjec ... Connection
- http://tools.cherrypy.org/wiki/Databases

mfg
Gerold

[gerold]

Hallo blackbird!

MySQL zb öffnet gestorbene Verbindungen nicht automatisch neu.

Wenn so etwas öfter vor kommt, dann kann man ja etwas dagegen tun:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-15 -*-

import psycopg2
import cherrypy

DSN = "dbname='postgres' user='irgendeiner' host='localhost' password='irgendeines'"


def get_conn():
    try:
        conn = cherrypy.thread_data.connection
        # Connection testen
        cur = conn.cursor()
        cur.execute("SELECT CURRENT_TIMESTAMP")
        cur.fetchone()
    except (NameError, psycopg2.ProgrammingError):
        conn = cherrypy.thread_data.connection = psycopg2.connect(DSN)
    
    return conn 

#...

Ich halte diesen Overhead für verschwindend gering. Deshalb hätte ich auch unter Server-Vollast kein Problem damit.

nicht zwei Verbindungen in einen Thread holen

``get_conn1()`` und ``get_conn2()``
Viel mehr, gleichzeitig offene, Verbindungen je Thread werde ich selten benötigen. Man kann es sicher andes lösen, aber sicher nicht einfacher.

eine Transaktion beenden lassen während der User schon seine Seite bekommen hat.

An so einen Fall kann ich mich jetzt nicht erinnern. -- Darüber habe ich noch nicht nachgedacht. Da müsste man wahrscheinlich irgendwie mit einer globalen Datenbankverbindung arbeiten, die dann die Jobs per Queue bekommt. So z.B.: http://aspn.activestate.com/ASPN/Cookbo ... ipe/496799

lg
Gerold