Lieder zwischen zwei Installationen Synchronisieren (Idee)

Hallo Zusammen,

 

ich hab mir überlegt ob es wohl möglich währe die Liederdatenbank zwieschen zwei OpenLP-Installationen zu synchronisieren.

Warum?

Wir planen zwei Installationen. Eine im Jugendbereich und eine Weitere im Gemeindeforum.

Jetzt wäre es natürlich toll wenn Jugend und Forum auf die Selbe Datenbank zugreifen könnten oder Ihre Stände von Zeit zu Zeit synchronisieren könnten.

Meine Idee:

Man könnte das entsprechende Verzeichnis mit UNISON synchronisieren. Evtl. Indem man einen Zwischenschritt über eine Webdienst wie Dropbox macht.

http://de.wikipedia.org/wiki/Unison_(Software)
http://www.cis.upenn.edu/~bcpierce/unison/

Wer kann beuteilen ob sowas funktionieren kann ohne daß man sich gegenseitig die Datenbanken "abschießt"?

 

Gruß

 

Questions

Comments

  • Naja,
    Leider hat hier kaum Jemand die gleiche Fragen wie ich.
    Etwas Recherche hat mir gezeigt,d aß man die Daten von OpenLP über ein Netzlaufwerk (z.B.: UbuntuOne, OwnCloud oder DropBox) teilen kann. Das ist aber nicht ohne Risiko, weil es zu Fehlzugriffen kommen kann.
    In den englischen Foren wird immer wieder darüber geschrieben. Also ist das Thema nicht so uninteressant. Ich fänds cool, wenn in 2.2 ein Erweiterung in dieser Richtung erfolgen würde.

    Gruß Questions
  • Hey,

    Man kann OpenLP auch über das Internet betreiben. Also die Datenbank ist dann nicht mehr lokal. Diese Funktion ist aber höchst experimentell. http://wiki.openlp.org/OpenLP_2_Introduction_and_FAQ#.28Advanced.29_Using_MySQL_or_PostgreSQL_to_store_songs

    Gruß
  • Hi Googol,

    dank für die Info. Das hatte ich mir schon angesehen. Mein Problem dabei:
    Was ist wenn zwei User auf die selbe Datenbank zugreifen? Wenn mein Englisch reicht wird genau das nicht ausgeschlossen.
    Was passiert wenn bei Dieser Lösung zwei User auf diese Datenbank zugreifen?
    Wir haben zwar keine zwei parallelen Gottesdienste aber in der Vorbereitungsphase tobte bisher  in unserer DropBox das Chaos. Das würde dann voll auf die DB durchschlagen.

    Ob ich die Datenbank oder das Datenverzeichnis in die DropBox verlege ist doch von der Wirkung her das Gleiche, oder?

    Bitte nicht falsch verstehen. Der Ansatz geht genau in meine Richtung, nur ist er im Moment noch nicht sicher genug oder ich hab ihn noch nicht ganz verstanden. Dann korrigiere mich bitte!

    Gruß Questions

  • edited June 2013
    Wenn man z. B mysql als Datenbank nimmt, dann können mehrere Nutzer die Lieder usw. bearbeiten. Nur wenn das gleiche Lied zur selben Zeit bearbeite wird, gibt es Probleme.

    Aber wie gesagt diese Funktion ist noch sehr getestet.

    Gruß

    PS: Es scheint, als würden viele die Datenbank in der Dropbox speichern, Dazu muss man aber sagen, dass das rein technisch eine sehr heikle Angelegenheit ist. Besonders dann, wenn verschiedene Nutzer die Datenbank gleichzeitig benutzen wollen.
  • Hallo Googol,

    danke für Deine Antwort.
    Genau das mit Dropbox mach ich im Moment auch. Das mit der Sql-Datenbank ist schon ne Idee, nur wo liegt die dann, bzw. Was ist wenn mal das Internet net geht. Das hatten wir schonmal, ist echt doof wenn man davon so abhängig ist.
    Bei Dropbox hat man dann immernoch die lokale Kopie und der Gottesdienst kann steigen.

    Gruß Questions
  • Wenn ich mich mal einmischen darf...
    SQLite ist toll für den Einsatz auf einem Einzelrechner. Sobald ich jedoch mehrere Clients habe, ist SQLite schlichtweg nicht dafür gemacht. Hier müsste dann wirklich ein DBMS wie Postgres oder MySQL verwendet werden.
    Ein ganz anderer Weg wäre, von der SQL-Schiene wegzugehen und die Lieder in einer NoSQL-Datenbank zu speichern. Hier gibt es schöne Möglichkeiten, die Daten z.B. in XML-Files zu speichern. Das Ganze dann mit einem Versionsverwaltungssystem a la git gekoppelt macht das System ziemlich gut handhabbar: Globales Repository irgendwo im Netz, lokale Repositories, mit denen gearbeitet wird.

    Das ist nur mal so dahergesponnen, ich hab mit einer solchen Kombination keine Erfahrung. Aber grundsätzlich könnte ich mir vorstellen, dass das geht und auch recht gut für Laien handhabbar ist.

    Gruß
    Oli
  • Puh, also ich würde von einer NoSQL-Datenbank dringend Abstand nehmen. Meine Erfahrungen diesbezüglich sind wirklich niederschmetternd. Was spricht gegen eine Lösung mit einer beliebigen SQL-Datenbank? Auch dort ist ein Mehrbenutzersystem handelbar.
    Es ist meiner Meinung nach eh fraglich, inwiefern man ein Mehrbenutzersystem für diese Art von Software nutzen und brauchen kann.
  • Hallo,

    dann misch ich mich kurz mit zwei Beispielen aus meiner Praxis ein:
    1. Zwei-User-Betrieb wär für mich, wenn ich einen Rechner in der Gemeinde hab und einen zu Hause und von dem zuhause die Datenbank von dem Rechner in der Gemeinde waren kann.
    2. Mehr-User-Betrieb wäre wenn dann noch ein weiterer Admin oder ein weiterer Rechner in der Jugend dazu kommen.
    Ich find die Idee mit der Versionsverwaltung ganz interessant, weil, wenn ich das richtig verstanden habe, immer eine lokale Kopie der Datenbank zur Verfügung steht, auch wenn's Internet grad net geht. Das ist für mich ein wichtiger Punkt.

    Gruß Questions
  • @tuetenelch: hmm, inwiefern hast Du denn negative Erfahrungen gemacht? Ich selber kenn die Dinger nur aus der Theorie, daher bin ich da ein bisschen unbedarft...
    Ein "richtiges" SQL-System wie MySQL und Konsorten finde ich erstens ein bisschen zu aufgebläht, und zum zweiten arbeite ich unheimlich gern mit Versionverwaltungssystemen und habe da schon sehr gute Erfahrungn mit verteiltem Arbeiten gemacht. Und ne MySQL-DB kannst du einfach schlecht mit Git und Co. verheiraten.
    Aber ich bin hier neu, und die Dinge die ich hier anspreche sind bestimmt alle schonmal diskutiert worden, daher nehmt es mir bitte nicht krumm, wenn ich hier mit spinnigen Ideen komme ;-)
  • Also wir sollten glaube ich erstmal die Begriffe etwas entwirren. Man unterscheidet zwischen relationalen Datenbanken (mit denen fast immer - aber nicht ausschließlich - per SQL kommuniziert wird) und nichtrelationalen Datenbanken (Schlagwort noSQL, was aber einen ganzen Haufen von Datenbanktypen abdeckt). Grundsätzlich sollte man sich Gedanken machen, warum man ein bestimmtes Konzept benutzt, aber noch mehr, warum man ein bestehendes Konzept ablösen möchte. Was sind denn die konkreten Vorteile, eine nichtrelationale Datenbank für OpenLP zu nutzen?
    Es gibt übrigens auch ganz viele andere SQL-Datenbanken die nicht MySQL heißen und alle ihre Vor- und Nachteile haben - und eben gar nicht so aufgebläht (wieso eigentlich?) daherkommen. Man muss ja auch nicht unbedingt eine externe Versionsverwaltung benutzen. Warum nicht die verschiedenen Speicherstände in der Datenbank speichern? Das machen andere Anwendungen ja auch so.
    Ehrlich gesagt weiß ich nicht, ob diese Dinge schon diskutiert wurden - ich bin genauso neu :)

    Zu den beiden Szenarien die oben geschildert wurden möchte ich auch etwas anmerken. Ich gehe jetzt einfach davon aus, dass die Lieddatenbank soweit fertig bestückt ist und das im Monat nicht mehr als ein oder zwei neue Lieder dazu kommen.
    ad 1) Der Rechner zuhause und in der Gemeinde besitzen die gleiche Datenbank. Zuhause wird ein neues Lied eingegeben und einem Ablaufplan hinzugefügt. Aktiviert man die Option "Neue Lieder automatisch hinzufügen", wird in der Gemeinde sofort wenn der Ablaufplan mit dem neuen Lied geladen wird, dieses der Datenbank hinzugefügt. Wieso also aufwendig synchronisieren?
    ad 2) Auch bei mehreren PCs reicht eine regelmäßige, automatisierte oder manuelle Sznchronisierung eigentlich aus.
    Ich gebe aber zu, dass gerade in der Anfangsphase halt eine enorme Zirkulation von Liedern stattfindet.

    Mein Problem mit all diesen Synchronisierungsansätzen ist halt auch der Punkt, dass die Daten von allen Rechnern erreichbar sein müssen, also idealerweise irgendwo "im Internet" verfügbar sind. Ich könnte mir vorstellen, dass man da einen immensen Aufwand treiben muss um nicht illegal geschütztes Material (Liedtexte) mehr oder weniger offen zu speichern. Auch wird es problematisch, wenn sensible Daten (und das sind z.B. Ankündigungen oft) dort gelagert werden. Streng genommen darf man nämlich nach deutschem Recht nicht mal einen Namen bei Anbietern wie Dropbox hinterlegen.

    Also ich will nichts ausreden (im Gegenteil, ich finde den Punkt sehr wichtig!) sondern würde mich einfach über eine Diskussion freuen.
  • Hallo,
    ich interessiere mich auch für eine Synchronisierung. Neben dem Rechner in der Gemeinde (der meist nicht im Internet ist) sind da auch noch die 5-8 Leute (Techniker, Band), die zu Hause neue Lieder einpflegen.
    Von Arbeit her bin vom Umgang mit einem SVN ganz angetan, was für weniger technik-affine Nutzer aber wahrscheinlich schwierig wird. Ansonsten wäre dieser Ansatz mit lokalen Arbeitskopien (will mich bei keiner Veranstaltung auf das UMTS-Internet verlassen müssen), Locks (liedweise), Versionierung, zentralem Datenspeicher etc. in meinen Augen schon sinnvoll. Die Abläufe können ja dann als Dateien auch einfach mit ins SVN ...
    Zum Thema "Im Internet verfügbar": So ein SVN betreibt man idR mit Benutzerauthentifizierung, die Kommunikation kann verschlüsselt über SSH geschehen. Da habe ich wenig Bedenken.
  • Hallo zusammen

    Ich finde es enorm wichtig, dass die Daten von verschiedenen Rechnern aus abrufbar sind. So können z.B. die Lobpreisleiter von zuhause aus die aktuellen Abläufe bearbeiten. Sie können so auch mit den aktuellen Liederdatenbanken arbeiten usw.

    Der Zweck einer Datenbank wie MySQL ist es ja, das gleich mehrere Anwendungen oder mehrere User gleichzeitig auf die Datenbank zugreifen können. Das Abspeichern eines Datensatzes geschieht ja meistens in der Geschwindikeit von milli-sekunden, also von da her sehe ich jetzt bei Open-LP nicht wirklich ein grosses Problem. Klar, kann es vor kommen, dass wenn zwei User gleichzeitig ein Lied bearbeiten, sich gegenseitig mit ihrer Eingabe über speichern. Aber ich denke das währe wirklich ein Zufall.

    Viel grösser ist die Frage, wie man die Hintergründe synchronisiert. Denn wenn man die Lieder über die Datenbank laufen lässt, müsste man eigentlich die Grafiken ebenfalls in der DB speichern.

    Für eine Datenbanklösung spricht auch das Backup. Man braucht nämlich nur die Datenbank zu sichern und schon hat man ein komplettes Backup der Lieder, Einstellungen usw...

    Die einzige Schwirigkeit ist wirklich der offline betrieb. Meiner Meinung nach muss ein Präsentationssystem offline laufen und sollte nicht vom Netz abhängig sein ... Eine akzeptable Lösung währe, wenn die Datenbank auf einem Server in der Gemeinde gespeichert wird und man per LAN darauf zugreifen kann. Wenn dann der Präsentations Computer via Kabel mit dem LAN verbunden ist, läuft das ganze ziemlich stabil ...

    Ich persönlich würde eine Datenbanklösung sehr begrüssen und freue mich auch, das dies nun scheinbar möglich ist.
  • >Eine akzeptable Lösung währe, wenn die Datenbank auf einem Server in der

    > Gemeinde gespeichert wird und man per LAN darauf zugreifen kann

    Ja, aber nur in einer bestimmten Gemeinde.
    Wenn man sein OLP öfters mal woanders hin mitnimmt (so, wie ich), benötigt man i.d.R. doch wieder eine Standalone-Lösung.
    Sehrwahrscheinlich müsste man über das Thema Datenbankreplikation nachdenken, d.h. Offline-DB synchronisiert sich mit Online-DB.

    Gruß Walter
  • Dass Leute gleichzeitig das selbe Lied editieren, mag vielleicht unwahrscheinlich erscheinen, kommt aber in der Praxis durchaus vor (Samstag Abend, da fehlen noch 2 Lieder für morgen, und das fällt Band und Techniker(n) gleichzeitig auf ... alles schon passiert :-D ). M.E. sollte man das, wenn man eh ein Konzept erarbeitet, von vorn herein adressieren.

    Ich bin inzwischen der Meinung, dass ein Tool zum Synchronisieren der SQLite-Offline-Datenbanken funktionieren müsste. Im ersten Ansatz auch ohne Integration in OpenLP:
    1. Sicherstellen, dass OpenLP nicht läuft
    2. Entfernte SQLite-Datei vom Server laden und dort eine (eventuell mit Usernamen versehene) .lock-Datei ablegen (damit in der Zeit niemand anderes synchronisieren kann und die anderen wissen, wer gerade synchronisiert)
    3. Datenbanken synchronisieren, incl. Möglichkeit zur Konfliktbehandlung (Bei Liedern: Unterschiede zwischen entfernter und lokaler Version anzeigen; Möglichkeit, die eine oder die andere zu überschreiben; Möglichkeit, den Lock gesetzt zu lassen und in OpenLP zu editieren)
    4. Aktuelle SQLite-Datei wieder auf den Server laden, Lock entfernen
    Anweisung an die "Liedeintipper" wäre dann, die Synchronisation direkt vor und nach dem Benutzen von OpenLP durchzuführen. Durch zusätzliche organisatorische Maßnahmen (Absprachen) sollte man natürlich versuchen, Konflikte so gering wie möglich zu halten.

    "Server" würde ich im Sinne von "Ort zum Speichern von Dateien" gern so weit wie möglich fassen: Ordner im Dateisystem (z.B. USB-Stick), WebDAV, SFTP, ... . Vielleicht kann man dem Nutzer auch zumuten, das Mounten des entfernten Datenspeichers selbst zu übernehmen, so dass man es immer nur mit einem Ordner im Dateisystem zu tun hat.
    Einige der Ideen stammen von Unison (zum Synchronisieren von Dateien).
  • edited September 2013
    Datenbankreplikation finde ich am spannendsten. Das würde bedeuten, dass es z.B einen MySQL Server gibt der über das Netz erreichbar ist. Sobald man OLP startet synchronisiert es die Lieder zwischen der MySQL Datenbank und der lokalen SQLite-Datei ab. Sobald diese Datei wieder verändert wird, wird der Datensatz mit dem Server abgeglichen, sofern er erreichbar ist. Ansonsten halt erst, wenn er wieder erreichbar wird.

    Wenn inzwischen ein Lied doppelt bearbeitet wird, würde OLP beim Synchronisieren die zwei verschiedenen Datensätze anzeigen und fragen, welchen übernommen werden soll...

    Machbar ist vieles, man muss es nur programmieren ;o)
  • Das Tool muss folgende Anforderungen haben: 

    1. Multiuser-fähig ohne Daten zu zerstören 
    2. Synchronisieren mit Erkennung von beidseitigen Änderungen und 
    2a Mergen falls erforderlich, am besten mit Liedvorschau
    3. Serverfähig sein, aber 
    4. Trotzdem lokale Kopien erhalten, mit denen OpenLP laufen kann.

    Das Verfahren würde dann so aussehen:

    - OpenLP wird über den Wrapper gestartet. Dieser synchronisiert zuerst die lokale Datenbank mit dem Server (falls möglich), startet dann OpenLP und verschwindet wieder im Hintergrund.
    - Sobald OpenLP geschlossen wird, wird die Datenbank zurück synchronisiert (falls möglich).
    - Falls keine Verbindung besteht, wird einfach beim nächsten Start synchronisiert.
    - Wird OpenLP ohne das Tool gestartet, müssen Änderungen ebenfalls einwandfrei erkannt und synchronisiert werden.
    - Falls während des Betriebes von OpenLP die Serverdatenbank durch den Multiuser betrieb geändert wird, muss das behandelt und evtl. gemerged werden.

    #warum während des Betriebes? Warum nicht einfach die DB sperren, während OpenLP läuft? Ganz einfach, was wäre, wenn jemand den PC anlässt und das Tool läuft, aber z.B. schlafen geht? Niemand könnte mehr daran arbeiten, weil die DB gesperrt ist. -> Sperrzeiten so kurz wie möglich halten.

    - Es muss erkannt werden, an welchen Datensätzen änderungen vorgenommen wurden, um den Benutzer nicht mit >9000 Liedern zu Bombadieren, wovon nur eines geändert wurde.
    - Die Lieder sollten übersichtlich ausgegeben werden: In der DB steht XML. Auch die Reihenfolge der Verse sollte beachtet werden.

    Hohe Anforderungen :) Mal schauen, was die nächsten Wochen daraus wird. Geschrieben wird das ganze allerdings nicht Plattformunabhängig, da ich .NET und WPF benutzen werde. Da .NET aber in MONO ein unabhängiges äquivalent hat, und WPF sehr strikt Design von Logik trennt, wird die Portierung auf andere Plattformen mit hoher wahrscheinlichkeit ohne größere Schwierigkeiten möglich sein.
  • Mono hinkt .Net meines Wissens immer ein Stück hinterher. Am besten guckst Du nach, auf welchem .Net - Stand Mono ist, falls es mal eine Portierung geben soll.

    Gruß Walter
  • edited January 2014
    Ich hab ja jetzt mal länger nichts mehr von mir hören lassen, aber mein Studium und meine anderen Projekte halten die Entwicklung ein bisschen auf.

    Als Update: Man kann nun die Einstellungen setzen und verändern. Die Einstellungen werden verschlüsselt in einer Datenbank im unterordner "sync" gehalten (%appdata%\openlp\sync / Portabler Pfad). Die Einstellungen sind Modular gestaltet. Das heißt, momentan bin ich dabei, die Synchronisierung mit MySQL zu schreiben, aber man kann das Programm um jede Methode erweitern (Netzwerkordner, Dropbox).

    Leute, die gerne up-to-date bleiben, können den Sourcecode einsehen und gerne mal Kompilieren, falls sie neugierig sind ;)

    EDIT: Zum effektiven einsehen und kompilieren des Projekts benötigt ihr eine C#-Programmierumgebung. Ich benutze VisualStudio 2012, davon gibt es auch kostenlose Versionen, die jeder benutzen kann.
  • Hallo,

    Möchtest du  nicht lieber am offiziellen Code mitarbeiten? Die Hürden dafür sind sehr niedrig. Außerdem profitieren dann alle Nutzer davon.

    Ich habe mir zwar nicht genau angeschaut, was du programmiert hast, aber OpenLP kann auch mit einer MySQL Datenbank sprechen (http://wiki.openlp.org/OpenLP_2_Introduction_and_FAQ#.28Advanced.29_Using_MySQL_or_PostgreSQL_to_store_songs). Nur is das experimentell und wenig getestet. (Ich weiß den LInk habe ich oben schon einmal gepostet.)

    Gruß,
    Andreas
  • Ich antworte auf die ursprüngliche Frage:

    Wir verwenden Dropbox (jeder andere Dienst, der einen lokalen Ordner "in the cloud" spiegelt sollte gehen). Es dürfen nur nicht mehrere Rechner gleichzeitig in zentralen "Datenbankdatei" schreiben wollen. Bei uns ist das aber kein Problem.

    Auf allen Rechnern ist ein normale OpenLP-Version (nicht portable) installiert. Das OpenLP-Datenverzeichnis liegt im Dropbox-Ordner (der Pfad muss im Einstellungsmenü entsprechend gewählt werden) und wird somit zwischen den Installationen syncronisiert.

    Diese Lösung erfordert kein besonderes Wissen und läuft schon mit der aktuellen OpenLP-Version.
  • Abgesehen von den rechtlichen Bedenken beim Umgang mit Dropbox bringt die Lösung, Daten "in der Cloud" zu lagern eben auch die bekannten Synchronisierungsprobleme mit sich.
    Die Lösung von CShark schließt leider einen großen Teil der Anwender aus - die, die einen Mac oder Linuxpc nutzen.
    Die Synchronisierung sollte wenn als Teil von OpenLP selber implementiert werden, alles andere ist mehr oder weniger sinnlos.
    Grundsätzlich benötigen die Daten in den Tabellen eindeutige Datumsangaben, soweit ich mich erinnere sind diese in OpenLP derzeit nicht vorgesehen (korrigiert mich sonst!).
    Sonst kann eine "einrichtungs" Synchronisierung von einem zentralen Server zu einer lokalen Kopie ja schon jetzt per mysqldump und cronjob realisiert werden. 
  • Hallo Zusammen,

    super, dass sich inzwischen so viele beteiligen! Nach langem Schweigen will ich mich auch mal wieder ein wenig beteiligen und ein paar Punkte der Reihe nach beantworten:

    @tuetenelch: Was Deine Annahmen zu neuen Lieder angeht kann ich Dir aus meiner Praxis nur teilweise recht geben. Unsere Jugend pflegt fast wöchentlich neue Lieder ein. Und das obwohl wir OpenLP jetzt scho ein Jahr im Einsatz haben!
    Den Import von unbekannten Lieder aus dem Ablauf hab ich bewusst deaktiviert weil es sehr häufig vorkommt, dass das gleiche Lied unter unterschiedlichen Titeln gespeichert wird. Dann bekommt man sehr schnell ein Chaos. Vor OpenLP haben wir unsere Lieder mit PPT dargestellt dort hatten wir genau dieses Problem. Beim Import in OpenLP hab ich die 2500 Datein auf unter 1000 ausgedünnt, weil der Rest Duplikate waren. Jetzt da wir das gerade gezogen haben möchte ich vermeiden, dass dieses Chaos erneut um sich greift. Also darf bei uns nicht Jeder neue Lieder einplegen sindern nur der Admin uns sein Assistent.

    @GermanGospel:
    Das mit Dropbox machen wir gerade. Es klappt aber nur bedingt. Es kommt immer wieder zu "in konflikt stehenden Kopien" von "songs.sqlite". Daher würde ich eine saubere Lösung wie die hier diskutierte super finden.

    @All:
    Was die Anforderungen und den Funktinsplan angeht hab ich nichts mehr hinzu zu fügen. Mit den letzten Posts gehe ich konform.
    Nur muß ich tuetenelch recht geben: Es sollten unbedingt alle User berücksichtiget werden! Wir habe bei uns alle Versionen im Einsatz von Linux über Win bis Mac.
    Ich hab mir mal ein paar Wettbewerber angesehen. Ich hab keine Worshipsoftware gefunden die so eine Funktion bietet. Das wäre also ein richtig cooles Alleistellungsmerkmal!
    Am Programmieren kann ich mich nicht beteiligen, davon hab ich keine Ahnung. Bei einer gewissen Reife beteilige ich mich aber gern am Testen!

    Soweit mal von mir. Freu mich über weitere Beiträge und bin gespannt wozu das noch führt.
  • Hallo allerseits,
    gibt es zu der Synchronisations-Thematik Neuigkeiten? Ist das irgendwie in die Entwicklung eingeflossen, oder ist das komplett untergegangen?
    Wir haben die Herausforderung nach wie vor :-(
Sign In or Register to comment.