CouchBase Lite - Couchbase Objective-C

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • CouchBase Lite - Couchbase Objective-C

    Servus! Hat wer Erfahrung mit Couchbase Lite (vorher TouchDB) in Objective-C? - Insbesondere die Synchronisation mit der Online CouchDB?
    Funzt das gut?

    Bin für jede Rezession dankbar..

  • Wie regelmäßig änderst Du Dein Datenmodell?
    Die Arbeit, Deine CouchDB anzupassen, hast Du ebenfalls.
    Ich verstehe den Grund der Frage nicht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • markusschalk schrieb:

    matz schrieb:

    Mit der richtigen Migration kann CoreData auch mit geänderten Datenmodellen umgehen ;)


    Jap, hab ich mal gelesen.
    Simple ist aber etwas anderes..
    Eigentlich ist das ziemlich simpel. Oder genauer: So simpel wie es für den Anwendungsfall eben geht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Marco Feltmann schrieb:

    Wie regelmäßig änderst Du Dein Datenmodell?
    Die Arbeit, Deine CouchDB anzupassen, hast Du ebenfalls.
    Ich verstehe den Grund der Frage nicht.


    Amin Negm-Awad schrieb:

    markusschalk schrieb:

    matz schrieb:

    Mit der richtigen Migration kann CoreData auch mit geänderten Datenmodellen umgehen ;)


    Jap, hab ich mal gelesen.
    Simple ist aber etwas anderes..
    Eigentlich ist das ziemlich simpel. Oder genauer: So simpel wie es für den Anwendungsfall eben geht.


    Ich versuche es zu erklären. Also ich bekomme Daten in Form von Excel Dateien. Diese sind logischerweise nicht ausnormalisiert. Im Moment hab ich bspw. 3 Excelsheets. (Kletterhallen, Rodelbahnen, Fußballplätze). Diese haben unterschiedliche Attribute. In Zukunft werden weitere Excel-Sheets hinzukommen. (Z.B. Tennisplätze, Turnhallen - wieder unterschiedliche Attribute).
    Die ganzen Sheets werden per csv in parse.com (mongoDB) eingespielt.
    In meiner iOS App hol ich mir nun die Daten. Jede Spalte hat einen Datentyp. Für jeden Datentyp hab ich nun Custom Cells (Für Strings, NSNumbers hab ich eigene Cells. Dann hab ich Adressdaten, die eigene Cell haben und per Click AppleMaps öffnen..
    Ich frage im geparsten NSDictionary, welches ich von der RestApi bekomme ab, welcher Spalte welchen Typ hat. Ich hoffe man weiß, worauf ich hinaus will..

    Das ist Problem ist halt Core Data arbeitet mit SQLite als Backend, was halt nicht schemaless, wie MongoDB ist..
    Bin auch dankbar, wenn irgendwer eine bessere Vorgehensweise weiß.

  • Ich verstehe, dass Du da eine unidirektionale Verbindung hast.
    Also nur vom Server in Deine App.

    Warum speicherst Du dann nicht einfach das ja offensichtlich schon völlig fertige und an Deine UI entsprechend angepasste Dictionary auf dem Gerät ab?

    Davon abgesehen hast Du ja offensichtlich so etwas wie ein einheitliches dynamisches Format definiert.
    Wieso willst Du das in so etwas Statisches wie eine Datenbank stopfen?

    Und wenn Du auch in die andere Richtung arbeiten musst:
    Offensichtlich kann Dein Server aus dem wirren CSV ein ordentliches JSON Dictionary bauen.
    Dann wird es wohl auch nicht so schwer sein, aus einem JSON Dictionary ein ordentliches CSV zu bauen.

    Ich sehe hier absolut keinen Sinn in einer statischen Persistierung in einer Datenbank, wenn Du einen dynamischen Objektgraphen brauchst und hast.

    Natürlich kannst Du auch einfach Dein CoreData Modell dem Dictionary anpassen und entsprechend abstrahieren.
    Du hast ja offenbar nur Spaltenname, Datentyp der Spalte, Spalteninhalt. Das lässt sich sinngemäß mit NSString, Class, id abbilden.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Danke erstmal für deine Zeit Marco. :)Es kann sein, dass sich diese Daten ändern - (Infos wie Quadratmeter oder Sonstiges können hinzugefügt werden). Dazu sind Rezessionen durch den User möglich.
    Ich bräuchte also einen one way sync vom Server zum iDevice. Außerdem soll die App auch offlinefähig sein.
    Im WWW hab ich aber gelesen, dass dynamische Modelle in Core Data nicht empfehlenswert sind - Deswegen meine Frage, ob wer Erfahrung damit hat, Core Data Modelle mit Dictionary Keys zu erstellen oder wie in der initialen Fragestellung mit CouchDB Lite.

  • markusschalk schrieb:

    Im WWW hab ich aber gelesen, dass dynamische Modelle in Core Data nicht empfehlenswert sind

    Das kann ich so unterschreiben. Sie führen den Sinn Core Datas ad absurdum.
    Der Sinn Core Datas ist es, ganz im Stile der Entity-Relationship-Modellierung eine Kombination aus Entitäten und Relationen herzustellen, die persistent und in einem Guss existiert. Der Vorteil von Core Data liegt darin, diese Entity-Relationship-Modellage einfach zugreifbar, persistent und leicht benutzbar zu gestalten. Und auf dem Phone sorgt der SQLite Store auch noch dafür, dass Objekte ressourcenschonend erst bei Zugriff in den Speicher geladen werden.

    Du bekommst ein Dictionary mit all den Informationen, die Du benötigst. Dieses Dictionary ist variabel, jedes einzelne Objekt darin kann variabel sein. Es ist faktisch unmöglich, daraus ein Entity-Relationship-Modell zu generieren. Schließlich hast Du weder definierte Entitäten noch feste Abhängigkeiten.

    Dir selbst ist aufgefallen, dass du damit kein Entity-Relationship-Modell angelegt bekommst. Deshalb möchtest Du eine schemalose Datenbank wie mongoDB benutzen.
    Ich versuche nur, Dir zu erklären, dass das Unsinn ist und Du Dein benutztes NSDictionary einfach abspeichern kannst.

    Der Weg mit mongoDB wäre ja ungefähr dieser:
    1. Du nimmst Dein funktionierendes NSDictionary.
    2. Du wandelst es in für mongoDB verständliche JSON Dokumente um und erklärst der mongoDB dann gegebenenfalls noch, wie es diese Dokumente abzulegen hat.
    3. Du speicherst die JSON Dokumente in der mongoDB.
    4. Dann nimmst Du Deine JSON Dokumente aus der mongoDB.
    5. Du wandelst diese Dokumente in ein entsprechend funktionierendes NSDictionary um
    6. Du arbeitest damit weiter.


    Das sieht nach ganz schön viel Arbeit aus.

    Der Weg mit Cocoa Boardmitteln wäre dieser:
    1. Du nimmst Dein funktionierendes NSDictionary.
    2. Du speicherst Dein funktionierendes NSDictionary ab.
    3. Du lädst Dein funktionierendes NSDictionary.
    4. Du arbeitest damit weiter.

    Einzige Einschränkung: damit Du das NSDictionary serialisiert bekommst, müssen Deine darin liegenden Objekte das NSCoding Protokoll unterstützen.
    Die meisten Standardtypen von Cocoa unterstützen das von Hause aus, bei eigenen Objekten musst Du selbst zwei kleine Methoden implementieren.

    Vermutlich gibt es deshalb auch kaum Quellen zur Zusammenarbeit der beiden Konzepte.
    Was Dir mongoDB so anbietet, kann Cocoa quasi von Hause aus. Warum also mit Beidem arbeiten?
    Da mongoDB ebenso dokumentbasiert ist wie ein serialisiertes NSDictionary hast Du auch keinen der Vorteile von SQLite, also beispielsweise das verspätete Nachladen von Objekten erst bei direktem Zugriff. Es gibt einfach keinen Grund, mongoDB mit Cocoa oder GNUStep zu nutzen.
    (Und andere Objective-C Anwendungsgebiete sind mir nicht bekannt.)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Danke Marco für deine umfangreiche Antwort..Meine Fragestellungen wurden beantwortet. Das Serialisieren des Dictionaries mittels NSKeyedArchiver (plist,archiver) ist aber bei größeren Datenmengen inperformant bzw. bei Updates muss immer das gesamte File geladen bzw. geschrieben werden.
    Das möchte ich vermeiden. Deswegen verwende ich jetzt das CouchBase Lite Framework. Ich werde dann von meinen Erfahrungen berichten..

  • markusschalk schrieb:

    bei Updates muss immer das gesamte File geladen bzw. geschrieben werden.
    Das möchte ich vermeiden. Deswegen verwende ich jetzt das CouchBase Lite Framework.

    Da bin ich mal gespannt, wie Du das mit mongoDB vermeiden möchtest…
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • markusschalk schrieb:

    Eine schemalose CouchDB Lite ist sicher performanter als Plist bzw Archive Alternative.

    Wie kommst Du darauf?
    Wo hast Du die Performancevergleiche dazu gesehen?
    Beide arbeiten direkt mit Dateien zusammen. Keins von beidem ist ein rDBMS. Beide müssen bei einer Abfrage erst einmal alle "Datensätze" laden.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    markusschalk schrieb:

    Eine schemalose CouchDB Lite ist sicher performanter als Plist bzw Archive Alternative.

    Wie kommst Du darauf?
    Wo hast Du die Performancevergleiche dazu gesehen?
    Beide arbeiten direkt mit Dateien zusammen. Keins von beidem ist ein rDBMS. Beide müssen bei einer Abfrage erst einmal alle "Datensätze" laden.


    Durch die Caching Mechanismen denke ich, dass eine dokumentenbasierte DB Vorteile gegenüber Plists hat.
    Falls ich falsch liege, korrigiere mich bitte.

  • markusschalk schrieb:

    Marco Feltmann schrieb:

    markusschalk schrieb:

    Eine schemalose CouchDB Lite ist sicher performanter als Plist bzw Archive Alternative.

    Wie kommst Du darauf?
    Wo hast Du die Performancevergleiche dazu gesehen?
    Beide arbeiten direkt mit Dateien zusammen. Keins von beidem ist ein rDBMS. Beide müssen bei einer Abfrage erst einmal alle "Datensätze" laden.


    Durch die Caching Mechanismen denke ich, dass eine dokumentenbasierte DB Vorteile gegenüber Plists hat.
    Falls ich falsch liege, korrigiere mich bitte.

    Ich verstehe Deine Vermutung immer noch nicht so richtig.
    Welchen genauen Vorteil versprichst Du Dir davon, eine Abfrage an eine Datenbank zu schicken, die ihre Datensätze ausliest, in den RAM cached und bei Anfrage portionsweise zurückliefert gegenüber einem NSDictionary, welches seine Objekte im RAM hält und bei Anfrage Teile davon zurückliefert?

    Mich erinnert das an das ewige Browser-Gebashe. Chrome brauchte viel weniger CPU als Firefox – dafür aber das Dreifache an RAM. Safari unter Mac und der Internet Explorer unter Windows brauchte viel weniger RAM und CPU als Chrome – weil ihre integralen Bestandteile im OS verankert waren und die Last in den Diagnosetools entsprechend auf mehrere Prozesse ausgelagert wurden.

    Hier wird es dasselbe sein. Eventuell verbrauchen die aus der CouchDB generierten Objekte weniger RAM als ein NSDictionary. Du musst aber auch den RAM-Verbrauch des CouchDB Client in die Bilanz einrechnen.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:


    Wie kommst Du darauf?
    Wo hast Du die Performancevergleiche dazu gesehen?
    Beide arbeiten direkt mit Dateien zusammen. Keins von beidem ist ein rDBMS. Beide müssen bei einer Abfrage erst einmal alle "Datensätze" laden.

    Durch die Caching Mechanismen denke ich, dass eine dokumentenbasierte DB Vorteile gegenüber Plists hat.
    Falls ich falsch liege, korrigiere mich bitte.
    Ich verstehe Deine Vermutung immer noch nicht so richtig.
    Welchen genauen Vorteil versprichst Du Dir davon, eine Abfrage an eine Datenbank zu schicken, die ihre Datensätze ausliest, in den RAM cached und bei Anfrage portionsweise zurückliefert gegenüber einem NSDictionary, welches seine Objekte im RAM hält und bei Anfrage Teile davon zurückliefert?

    Mich erinnert das an das ewige Browser-Gebashe. Chrome brauchte viel weniger CPU als Firefox – dafür aber das Dreifache an RAM. Safari unter Mac und der Internet Explorer unter Windows brauchte viel weniger RAM und CPU als Chrome – weil ihre integralen Bestandteile im OS verankert waren und die Last in den Diagnosetools entsprechend auf mehrere Prozesse ausgelagert wurden.

    Hier wird es dasselbe sein. Eventuell verbrauchen die aus der CouchDB generierten Objekte weniger RAM als ein NSDictionary. Du musst aber auch den RAM-Verbrauch des CouchDB Client in die Bilanz einrechnen.

    Du hattest recht. Ich muss mich korrigieren.
    Der Benchmark zeigts..
    courses.cs.washington.edu/cour…projects/p19-tperrier.pdf