SQLite Server

[Leonidas]

Damit es nicht heißt ich spucke große Töne habe aber außer ein paar Codezeilen nichts zu bieten, habe ich mich irgendwann zwischen gestern und heute mal darangesetzt und SQLator stark ausgebaut. So habe ich meine Idee verschiedener Server umgesetzt.

Dazu gibt es ein(en) SQLatorB - Backbone/Backend, das die Datenbank öffnet und sie als Pyro-Objekt bereitstellt. Als weitere Ebene kommt SQLatorD - XML-RPC, die XML-RPC Version des Servers, sie entspricht dem Ur-Server, den ich hier vorgestellt habe. Als weiteres Schmankerl kam aber noch der SQLatorD - async hinzu, der alternativ zum XML-RPC Server verwendbar ist. Dieser Server ist eine Art XML-RPC mit persistenten Verbindungen und mit asyncore realisiert.
Zuletzt ist noch ein Client benötigt, dazu schlage ich den SQLatorC vor, dieser kann immernoch per 'echten' XML-RPC auf den Server zugreifen, als auch per async auf den neuen asyncore-Server (benötigt nur socket, die PySQLite-Bindungen sind auf dem Client unnötig).

Ich habe die IPC durch Pyro gelöst, weil Pyro eine Menge sehr praktischer Features hat, die auch in Zukunft praktisch sein könnten (wie z.B. ein Tuplespace). Also wird zum verwenden von SQLator noch Pyro (ich habe version 3.4 verwendet solange 3.5 noch in der Beta-Phase ist) benötigt, ich denke aber, das dies kein allzugroßes Problem sein sollte, denn Pyro ist unter MIT-Lizenz und 100% pures Python, somit kann man es auch zur Not mit ins Tarball packen.

Beim Schreiben des Servers mit asyncore ist mir aufgefallen, dass Sam Rushings Module großartig sind. Ich werde nie wieder einen Server in Python ohne asyncore (oder Twisted) schreiben, denn Event-gesteurte Netzwerkprogrammierung "fühlt" sich einfach viel besser an und die Programme schreiben sich wesentlich besser.

[tabellar]

Mir kommt das ganze ein bisschen überladen vor Mir ist noch nicht so ganz klar, warum du hier so viele Frameworks verwendest. Ich hab das ganze mal überflogen, aber noch nicht getestet. Ich bin kein Freund des endlosen Modul-Importierens...

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Die Asyncore/Asynchat Geschichte im SQLatorD gefällt mir ganz gut. Was mich ein wenig an deiner "allgemeinen XML-RPC" Verwendung stört, ist die allgemeine execute Funktion, die letztendlich die cur.fetchall() des Connection Objektes aufruft. Es gibt aber auch noch andere "Connection.Cursor Funktionen" ... Die Thematik habe ich bei meiner Socket/XML-RPC Version oben mal aufgezeigt.

Ich finde, das ganze sollte "leichtgewichtig" sein mit nicht zu vielen "import Modulen". Maximal Socket, Asyncore, Asynchat, PySQLite. Eine Alternative dazu wäre auch eine Variante mit SocketServer, Threading und Queue... (Clientverwaltung in jeweils einem eigenen Thread + Lock Mechanismus auf die Single-User-Datenbank ).

Ich muss mir das ganze aber auch noch mal genauer anschauen...
Tabellar

[Leonidas]

Mir kommt das ganze ein bisschen überladen vor Mir ist noch nicht so ganz klar, warum du hier so viele Frameworks verwendest. Ich hab das ganze mal überflogen, aber noch nicht getestet. Ich bin kein Freund des endlosen Modul-Importierens...

Ich verwende auußer PySQLite nur Pyro und das ist kein C-Modul, somit kann man es auch mit einpacken ohne dass es jegliche Probleme macht (und so groß ist pyro) auch nicht.

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen, die

Die Asyncore/Asynchat Geschichte im SQLatorD gefällt mir ganz gut. Was mich ein wenig an deiner "allgemeinen XML-RPC" Verwendung stört, ist die allgemeine execute Funktion, die letztendlich die cur.fetchall() des Connection Objektes aufruft. Es gibt aber auch noch andere "Connection.Cursor Funktionen" ... Die Thematik habe ich bei meiner Socket/XML-RPC Version oben mal aufgezeigt.

Ja, das war nur so zum testen ob es geht gedacht und kann sehr schnell korrigiert werden.

Ich finde, das ganze sollte "leichtgewichtig" sein mit nicht zu vielen "import Modulen". Maximal Socket, Asyncore, Asynchat, PySQLite. Eine Alternative dazu wäre auch eine Variante mit SocketServer, Threading und Queue... (Clientverwaltung in jeweils einem eigenen Thread + Lock Mechanismus auf die Single-User-Datenbank ).

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

[tabellar]

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen

Nun, auch wenn mehrere Server laufen würden, hätten diese auch nur ein "Connection" Objekt, welches sie von PySQLite erhalten. Sprich die Thematik für den Zugriff auf dieselbe DB wird dadurch nicht einfacher, sondern schwerer, weil die DB Zugriffe nicht mehr zentral gehandelt werden.

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Ich hab da schon ein paar ganz gute Beispiele ... Aber mir geht es gar nicht darum Pyro zu kopieren, sondern die Netzwerk Thematik besser verstehen zu lernen... Dies ist auch der Grund, warum ich mir andere Frameworks nicht gleich zu Nutze machen möchte.

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

Spassig ist dies ja allemal, und sich die Dinge anzuschauen bringt einen ja auch immer einen Schritt weiter...

Tabellar

[Leonidas]

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen

Nun, auch wenn mehrere Server laufen würden, hätten diese auch nur ein "Connection" Objekt, welches sie von PySQLite erhalten. Sprich die Thematik für den Zugriff auf dieselbe DB wird dadurch nicht einfacher, sondern schwerer, weil die DB Zugriffe nicht mehr zentral gehandelt werden.

Doch, die Zugriffe laufen alle über SQLiteB und werden somit zentral gehandhabt.

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Ich hab da schon ein paar ganz gute Beispiele ... Aber mir geht es gar nicht darum Pyro zu kopieren, sondern die Netzwerk Thematik besser verstehen zu lernen... Dies ist auch der Grund, warum ich mir andere Frameworks nicht gleich zu Nutze machen möchte.

Naja, ich verwende ganz gerne Sachen die schon funktionieren und sich erprobt haben, besonders wenn man dabei keine Nachteile hat.

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

Spassig ist dies ja allemal, und sich die Dinge anzuschauen bringt einen ja auch immer einen Schritt weiter...

Okay. Ich stell den online, wenn ich wieder zuhause bin. Du wirst sehen, dass der praktisch genauso funktioniert wie die async-Variante, also auch mit Factories und Protocols und XML-RPC kodierten Aufrufen. War ja auch praktisch ein Async-Port auf Twisted, mehr nicht.

[Leonidas]

Okay. Ich stell den online, wenn ich wieder zuhause bin. Du wirst sehen, dass der praktisch genauso funktioniert wie die async-Variante, also auch mit Factories und Protocols und XML-RPC kodierten Aufrufen. War ja auch praktisch ein Async-Port auf Twisted, mehr nicht.

Und den gibts nun hier. Darin wird sogar der LayerServer aus dem async-Server wiederverwendet.

[tabellar]

Also, ich hab die codes mal angeschaut, aber nicht getestet. Pyro scheint ja recht mächtig zu sein
und hat sein Augenmerk auf im Netzwerk verteilte Objekte gelegt (Pyro=Python Remote Objects).
Proxy, DNS, ... alles an Bord. Auch die auf der HP veröffentlichten Projekte, die Pyro verwenden, hören
sich recht interessant an.

Aber trotzdem, im Falle des SQLator Servers finde ich, dass die ganzen Frameworks nicht unbedingt
notwendig sind. Die Philosphie von SQLite selber ist ja der Minimalismus bei hoher Funktionalität
(sqlite3.dll = 241kB). Also sollte ein SQLite Server meiner Meinung nach auch eher lite sein .
Ich finde der Server ist das eine, und die Zugriffs API, wie z.B. XML-RPC, oder Python DB API 2.O ist das andere.
Man muss also unterscheiden, was man genau will. Denkbar wäre also, einen einfachen SQLatrorD zu bauen,
der TCP Grundfunktionalität zur Verfügung stellt und auf den über entsprechende, importierte API Module
(SQLatorDXmlRpcAPI, SQLatorDAPI2.0), zugegriffen werden kann.

Ich hab vorgestern mal einen einfachen SQLatorD mit User Authentifizierung gebaut. Der Client meldet sich beim Server an, der Server fragt
nach Username und Passwort, wenn die Daten passen wird die Connection aufrechterhalten und der Client kann entsprechend
mit dem Server kommunizieren...


Tabellar

[Leonidas]

Mit anderen worten, dich stört eigentlich nur Pyro? Na, ich werd mal schauen wie es ohne pyro aussieht, jedoch muss ich zugeben, dass die Features die einem mit Pyro offenstehen wirklich ziemlich interessant sind.

Wie wird es eigentlich bei jabberd gehandhabt? Da ist doch auch der Server mit einer SQL Datenbank verbunden, die noch laufen muss?

[tabellar]

Mit anderen worten, dich stört eigentlich nur Pyro? Na, ich werd mal schauen wie es ohne pyro aussieht, jedoch muss ich zugeben, dass die Features die einem mit Pyro offenstehen wirklich ziemlich interessant sind.

Mich stört Pyro nicht, im Gegenteil ... . Ich finde den Ansatz von Pyro - persistente, verteilte Objekte im Netz - sogar SEHR interessant. Aber nicht im Zusammenhang mit dem SQLatorD... Wenn man das ganze mal rein auf die Serverfunktionalität runterbricht, dann brauchen wir:

- TCP Connection (Kommunikation: Daten send/recv)
- Thread je Client
- PySQLite Connection Objekt je Thread

Alles andere sind Zugaben und Wünsche...

Wie wird es eigentlich bei jabberd gehandhabt? Da ist doch auch der Server mit einer SQL Datenbank verbunden, die noch laufen muss?

Da läuft das ganze ein wenig anders. Die jabberd(Backbone) Architektur ist konsequent auf Schnittstellen und Komponenten aufgebaut. Die meisten Komponenten sind über die TCP/Socket Schnittstelle angeschlossen. D.h., Komponente xyz ist als Client mit Adresse (Bsp.:"localhost",10001) mit dem jabberd in Verbindung. Austauschprotokoll ist das "JabberProtokoll" und ist in XML. Beim jabberd heisst die DB Komponente xdb. Über diese Komponente (eine Wrapper Komponente , laufen die ganzen DB Abfragen (user auth, vcard, etc.). Als DB Backend dienen im Normalfall reine XML DB files . Ab jabberd2 können aber auch "richtige" RDBMS angehängt werden .

Tabellar

[Leonidas]

Okay, dann hier mal der Async-SQLatorD ohne Pyro:

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon"""
import socket, asynchat, asyncore, xmlrpclib
from sqlatorb import SQLiteBackbone

class LayerServer(object):
    def __init__(self):
        self.storage = SQLiteBackbone()
        
    def execute(self, query):
        """Gets the query (XML-RPC request),
        decodes it to SQL, executes it, encodes the result
        into XML-RPC and returns it"""
        query = self.rpc_decode(query)
        result = self.storage.execute(query)
        return self.rpc_encode(result)
    
    def rpc_encode(self, data):
        return xmlrpclib.dumps((data,), methodresponse=True)
    
    def rpc_decode(self, data):
        params, methodname = xmlrpclib.loads(data)
        return params[0]
    

class ConnectionFactory(asyncore.dispatcher):
    def __init__(self):
        print 'Booting:'
        self.port = 5888
        print ' - Creating server instance'
        self.server = LayerServer()
        print ' - Calling dispatcher'
        asyncore.dispatcher.__init__(self)
        print ' - Creating socket'
        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
        print ' - Binding socket to port'
        self.bind(('', self.port))
        print ' - Listening: Booting done.'
        self.listen(5)
    
    def handle_accept(self):
        newSocket, address = self.accept()
        print 'Connected by %s:%d' % address
        ClientProtocol(socket=newSocket, server=self.server)


class ClientProtocol(asynchat.async_chat):
    def __init__(self, socket, server):
        print 'Connection delegated'
        self.server = server
        asynchat.async_chat.__init__(self, socket)
        self.set_terminator('\r\n')
        self.data = ""
    
    def collect_incoming_data(self, data):
        """Collects data got through the socket"""
        self.data += data

    def found_terminator(self):
        print self.data
        result = self.server.execute(self.data)
        self.push(result)
        #self.push(''.join(self.data))
        self.data = ""


def main():
    ConnectionFactory()
    asyncore.loop()

if __name__ == '__main__':
    main()

Der Rest bleibt unverändert, jedoch muss SQLatorB nicht extra gestartet werden (ich weiß, SQLatorB benötigt noch Pyro), und der CLient funktioniert weiterhin ohne jede Änderung.

Ich hatte jetzt keine Lust noch den XML-RPC SQLatorD umzuschreiben, und deinen Tipp, tabellar habe ich immer noch nicht eingebaut.

[tabellar]

Ich wollt mich mal schnell melden, denn ich bin gerade im Urlaub und deshalb (oder gerade deswegen) nicht so oft am Computer . Also bis bald, dann auch wieder konstruktiver .

Tabellar

[Leonidas]

Na dann wünsch ich dir gute Erholung und bis dann

[freq.9]

Ich beschäftige mich mit SQLite und habe hier grad mal reingeschaut. Habe mir auch versucht den aktuellsten Code zusammenzusuchen aber bin irgendwie durcheinander gekommen. Könnte da wohl jmd. mal ne kleine Zusammenfassung der Codes machen!? Oder gibts dazu vllt. ne Homepage?

[Leonidas]

Habe mir auch versucht den aktuellsten Code zusammenzusuchen aber bin irgendwie durcheinander gekommen.

Ja, es kann sein, dass wir im Thread etwas Chaos haben

Könnte da wohl jmd. mal ne kleine Zusammenfassung der Codes machen!? Oder gibts dazu vllt. ne Homepage?

Eine Homepage gibt es nicht, da es ja eigentlich eher eine Codeschnippselsammlung ist, die überraschend gut funktioniert. Der aktuellste Code ist im SVN Repository, am besten due lädst einfach mal alle Dateien runter, deren Namen mit sqlator anfangen. Es gibt im Moment fünf Dateien:

• sqlatorc.py - Der Client, kann sowohl mit "echtem" XML-RPC umgehen, als auch mit dem etwas modifiziertem
• sqlatorb.py - Der Backend-Server. Dieser stellt alle Funktionen zur Verfüngung, die die Frontend-Server benötigen, verwaltet also die Datenbank usw. Läuft im hintergrund und kommuniziert über Pyro mit den Frontend-Servern.
• sqlatord_xmlrpc.py - Der Frontend-Server für XML-RPC Verbindungen. Auf diesen greift der Client dann zu.
• sqlatord_async.py - Ein anderen Frontend Server der ein modifiziertes XML-RPC verwendet.
• sqlatord_twisted.py - Eine Alternative zu async, nutzt Twisted statt asyncore.

Du musst zuerst den Backend-Server starten, dann mindestens einen der Frontend Server (mehrere Server gleichzeitig sind auch möglich, das ist das tolle). Auf diese greift dann der Client zu. Aber wenn du SQLite nutzen willst, brauchst du SQLator eigentlich nicht! SQLator ist nur ein Versuch, die Netzwerkfunktionalität von PostgreSQL/MySQL nachzurüsten, mehr nicht.

Wenn du noch Fragen hast, nur zu!

[freq.9]

Cool, danke für die Zusammenstellung. Werd ich mir mal anschauen. Zur zeit frage ich mich noch wie das ganze arbeitet, da ich nur wenig Code sehe Werd ich mir dann mal anschauen

[Leonidas]

Zur zeit frage ich mich noch wie das ganze arbeitet, da ich nur wenig Code sehe

Das stimmt allerdings, es ist wirklich wenig Code, da ich größtenteils auf Sachen zugreife, die es bereits gibt. SQLator ist praktisch nur der Kleber, der es zusammenhält. Wobei es toll ist, was für nette Sachen man mit nur wenigen Zeilen Python-Code machen kann.

[tabellar]

Hier mal wieder ein Lebenszeichen von mir. Nach meinem Urlaub im
Sommer hatte ich kaum noch Zeit und Lust auf Rechner, Programmieren
designen etc. So langsam wird es wieder ...

Tabellar