Vielen Dank für Deine Antworten. Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Ich habe auf meinem System weger mysql noch postgresql noch deren libs installiert - brauche ich ja auch nicht nach Deiner Aussage. Denn beides sind vollausgewachsene RDBMS. Ohne jetzt eine Diskussion über mysql und deren Leistungsfähgikeit starten zu wollen.
Wie bekomme ich denn nun akonadi zum laufen? sqlite ist installiert, qt ist mit sqlite Unterstütung gebaut. akonadi will nicht, ich kann sqlite nicht mal auswählen.
Was tue ich dagegen? Ganz konkret?
Daher, zu meinen Annahmen eine offizielle Aussage, die Du sicher kennst: http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F
Ich wüßte nicht, was in Deinem Artkel steht, den ich sehr wohl gelesen habe, was meinen Aussgen irgendwie widerspricht. Du erwähnst sqlite als Backend, obiger Link und die Praxis sagen etwas anderes.
Es ist ein Cache, der ein SQL backend braucht. Laut Deinen Aussagen braucht es kein ausgewachsenes zu sein, also sind weder mysql noch postgres Pflicht. Ich habe beides nicht installiert und akonadi meckert.
sqlite soll laut Deinem Blog gehen, wird aber offiziell von abgeraten, siehe Link, und vor nicht allzu langer Zeit war die Unterstützung nicht offiziell, sondern ein Patch, "vorwiegend für mobile Geräte".
Also was nun? Abseits der üblich hohlen Trollschleimer, die sich hier wichtig tun, was ist verkehrt an meiner Aussage? Wie bekomme ich akonadi konkret ohne mysq oder postgresql zu laufen? Oder ist das eine Zukunftsversion?
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Also, Butter bei die Fische. Gibt es nur pseudo anti troll bashing oder auch handfestes? Vielleicht habe ich ja etwas übersehen in Deinem Blog?
Oder zieht Ihr euch bloß daran hoch, das ich der Auffassung bin, auf einen Desktop system hat ein RDBMS nix zu suchen und ein solches Design ist schon daneben. Wenn das alles ist, dann feiert euch mal schön selbst weiter.
Die Concurrencyprobleme in sqlite sind wie's scheint weitgehend gelöst, damit ist der Weg frei, auch ein SQLite Backend zu nutzen (und das ist soweit ich weiss auch der Fall für Kontact mobile). Mit deinen Setupproblemen kannst du Dich am besten an die KDE PIM Liste wenden.
Ich stimme Dir auch zu, dass der Storagemechanismus über verschiedene Apps geteilt werden sollte. Ist noch nicht der Fall, wird aber in Zukunft hoffentlich weiter so fortgesetzt.
Ansonsten finde ich die Aussage "dass auf einem Desktopsystem ein RDBMS nix zu suchen hat" eher unglücklich, und stimme ihr auch ganz einfach nicht zu. Gleiches gilt übrigens für Polemik um die du nicht herumzukommen scheinst. :/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Aug 2010 um 19:53.
Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Vermutlich 4.4.4oder früher. Das Problem wurde in 4.4.5 behoben. Es wurden eigentlich sogar Ressourcen gefunden, aber das Programm welches Akonadi gestartet hat, bekam dies nicht mit.
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Auf Akonadi trifft das noch viel mehr zu als auf Amarok, weil das ja immer noch ein KDE Programm ist, während Akonadi völlig unabhängig ist (es sitzt ja auch eine Stufe tiefer).
Generell ist das schon zumindest bei Nepomuk und Akonadi kein schlechter Ansatz, aber derzeit ist der SQL von Virtuoso (bzw. dessen Qt SQL Plugin) einfach noch nicht so weit um für Akonadi benutzbar zu sein.
Ich hatte auf der CeBIT 09 ein interessantes Gespräch mit einem Amarok Entwickler. Ich sprach ihn darauf an, wieso sie sich auf embedded MySQL festgelegt haben und als Quintessenz war wohl die Geschwindigkeit der ausschlaggebende Punkt. Ich fragte ihn dann nach einem ORM und der Möglichkeit dadurch beliebige RDBMS ansprechen zu können und musste dann erst einmal das ORM Konzept erläutern. Nun weiß ich nicht, ob es und was es an guten ORM für C++ gibt. Evtl. mag es an der Sprache liegen, dass man sich nicht für einen solchen Layer in Amarok entschieden hat - ich denke in Python hätte man definitiv auf sqlalchemy oder gar elixir gesetzt; das mag in C++ eben anders aussehen. Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Schade, dass ich in C++ nicht wirklich fit bin und zu wenig zeit habe
@sebas: Mach Dir nichts aus den Trollen und destruktiven Nörglern - es gibt auch Leser hier, die Deine Arbeit und die des gesamten KDE Teams toll finden und Deine Beiträge und Kommentare hier gerne lesen
Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Bei Akonadi wird praktisch so etwas gemacht. Aus einer Beschreibung der Datenobjekte in XML wird C++ Code für ihre Klassen und datenbankabhängig SQL Queries generiert (soweit ich mich richtig erinnere).
Leider gibt es speziell beim Setup als auch in einigen Abfragen Unterschiede, die man erst einmal händisch bearbeiten muss, bevor man neue Datenbanken unterstützen kann (sofern diese mal die Grundvorrausetzungen selbst erfüllen).
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Ich bin jetzt in Bezug auf diese dokumentorientierten Datenbanken nicht so am Laufenden, bzw. wie gut sie Relationen abbilden und abfragbar machen. Müsste sich halt mal jemand ansehen, der in diesem Bereich Erfahrung hat.
Vielen Dank für Deine Antworten. Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Ich habe auf meinem System weger mysql noch postgresql noch deren libs installiert - brauche ich ja auch nicht nach Deiner Aussage. Denn beides sind vollausgewachsene RDBMS. Ohne jetzt eine Diskussion über mysql und deren Leistungsfähgikeit starten zu wollen.
Wie bekomme ich denn nun akonadi zum laufen? sqlite ist installiert, qt ist mit sqlite Unterstütung gebaut. akonadi will nicht, ich kann sqlite nicht mal auswählen.
Was tue ich dagegen? Ganz konkret?
Daher, zu meinen Annahmen eine offizielle Aussage, die Du sicher kennst:
http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F
Ich wüßte nicht, was in Deinem Artkel steht, den ich sehr wohl gelesen habe, was meinen Aussgen irgendwie widerspricht. Du erwähnst sqlite als Backend, obiger Link und die Praxis sagen etwas anderes.
Es ist ein Cache, der ein SQL backend braucht. Laut Deinen Aussagen braucht es kein ausgewachsenes zu sein, also sind weder mysql noch postgres Pflicht. Ich habe beides nicht installiert und akonadi meckert.
sqlite soll laut Deinem Blog gehen, wird aber offiziell von abgeraten, siehe Link, und vor nicht allzu langer Zeit war die Unterstützung nicht offiziell, sondern ein Patch, "vorwiegend für mobile Geräte".
Also was nun? Abseits der üblich hohlen Trollschleimer, die sich hier wichtig tun, was ist verkehrt an meiner Aussage?
Wie bekomme ich akonadi konkret ohne mysq oder postgresql zu laufen? Oder ist das eine Zukunftsversion?
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Also, Butter bei die Fische. Gibt es nur pseudo anti troll bashing oder auch handfestes? Vielleicht habe ich ja etwas übersehen in Deinem Blog?
Oder zieht Ihr euch bloß daran hoch, das ich der Auffassung bin, auf einen Desktop system hat ein RDBMS nix zu suchen und ein solches Design ist schon daneben.
Wenn das alles ist, dann feiert euch mal schön selbst weiter.
Die Concurrencyprobleme in sqlite sind wie's scheint weitgehend gelöst, damit ist der Weg frei, auch ein SQLite Backend zu nutzen (und das ist soweit ich weiss auch der Fall für Kontact mobile). Mit deinen Setupproblemen kannst du Dich am besten an die KDE PIM Liste wenden.
Ich stimme Dir auch zu, dass der Storagemechanismus über verschiedene Apps geteilt werden sollte. Ist noch nicht der Fall, wird aber in Zukunft hoffentlich weiter so fortgesetzt.
Ansonsten finde ich die Aussage "dass auf einem Desktopsystem ein RDBMS nix zu suchen hat" eher unglücklich, und stimme ihr auch ganz einfach nicht zu. Gleiches gilt übrigens für Polemik um die du nicht herumzukommen scheinst. :/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Aug 2010 um 19:53.Vermutlich 4.4.4oder früher. Das Problem wurde in 4.4.5 behoben. Es wurden eigentlich sogar Ressourcen gefunden, aber das Programm welches Akonadi gestartet hat, bekam dies nicht mit.
Auf Akonadi trifft das noch viel mehr zu als auf Amarok, weil das ja immer noch ein KDE Programm ist, während Akonadi völlig unabhängig ist (es sitzt ja auch eine Stufe tiefer).
Generell ist das schon zumindest bei Nepomuk und Akonadi kein schlechter Ansatz, aber derzeit ist der SQL von Virtuoso (bzw. dessen Qt SQL Plugin) einfach noch nicht so weit um für Akonadi benutzbar zu sein.
Ich hatte auf der CeBIT 09 ein interessantes Gespräch mit einem Amarok Entwickler. Ich sprach ihn darauf an, wieso sie sich auf embedded MySQL festgelegt haben und als Quintessenz war wohl die Geschwindigkeit der ausschlaggebende Punkt. Ich fragte ihn dann nach einem ORM und der Möglichkeit dadurch beliebige RDBMS ansprechen zu können und musste dann erst einmal das ORM Konzept erläutern. Nun weiß ich nicht, ob es und was es an guten ORM für C++ gibt. Evtl. mag es an der Sprache liegen, dass man sich nicht für einen solchen Layer in Amarok entschieden hat - ich denke in Python hätte man definitiv auf sqlalchemy oder gar elixir gesetzt; das mag in C++ eben anders aussehen. Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Schade, dass ich in C++ nicht wirklich fit bin und zu wenig zeit habe
@sebas: Mach Dir nichts aus den Trollen und destruktiven Nörglern - es gibt auch Leser hier, die Deine Arbeit und die des gesamten KDE Teams toll finden und Deine Beiträge und Kommentare hier gerne lesen
Bei Akonadi wird praktisch so etwas gemacht. Aus einer Beschreibung der Datenobjekte in XML wird C++ Code für ihre Klassen und datenbankabhängig SQL Queries generiert (soweit ich mich richtig erinnere).
Leider gibt es speziell beim Setup als auch in einigen Abfragen Unterschiede, die man erst einmal händisch bearbeiten muss, bevor man neue Datenbanken unterstützen kann (sofern diese mal die Grundvorrausetzungen selbst erfüllen).
Ich bin jetzt in Bezug auf diese dokumentorientierten Datenbanken nicht so am Laufenden, bzw. wie gut sie Relationen abbilden und abfragbar machen.
Müsste sich halt mal jemand ansehen, der in diesem Bereich Erfahrung hat.