Server Client Core Data

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

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • Server Client Core Data

    Hallo

    Seit einigen Tagen versuche ich heraus zu finden, wie ich eine Server Client Applikation entwickeln könnte. Leider komme ich nicht weiter. Es gibt viele Ansätze, jedoch entspricht alles nicht ganz dem, was ich suche.

    Zu den Ansprüchen:
    - Auf den Server sollte von iOS sowie OS X Geräten zugegriffen werden sollen, Windows und Android ist optional und nicht so wichtig
    - Core Data sollte möglichst eingesetzt werden können, hier liegt der Knackpunkt, da Core Data ja nicht für Server Client Applikationen gedacht ist
    - Kommunikation über Internet sollte "sicher" stattfinden, sprich es sollte nicht in Klartext verschickt werden

    Ich würde gerne Core Data einsetzten, da es sich um wichtige Datensätze handelt und jede Änderung gespeichert werden muss. Sprich, wer hat welche Änderung wann vorgenommen. Mit dokumentbasierten Applikationen ist diese Möglichkeit gegeben, ohne viel Programmlogik zu schreiben, da Core Data die Änderungen speichert. Weshalb ich dies gerne nutzen würde.

    Incremental Stores hörten sich gut an, aber stellten sich als Sachgasse heraus, da sie auch nicht für Server Client Applikationen gedacht sind. Nun habe ich daran gedacht, eine Server Applikation zu schreiben, die Core Data Objekte verwaltet und mit den Clients austauscht.
    Gibt es für eine solche Lösung Ansätze oder Tutorials? Wobei ich nochmal auf die Versionierung der "Datensäzte" bzw Objekte hinweisen möchte.

    Gruß
    Kris
  • Core Data lässt sich doch sicherlich auch in Distributed Objects einpacken.
    Damit sollte die Kommunikation klappen. Wie du diese absicherst weiß ich nicht. Eventuell reicht ja einfaches HTTPS

    Da Core Data meines Wissens als Einzelplatzlösung geplant war, gibt es kein 'Versioning'.
    Zumal die Daten nicht in einem Multi-User-Datenbanksystem landen, halte ich es für die Client-Server-Architektur für ungeeignet.
    «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
  • Versionierung für Datensätze ... da gibt es diverse Möglichkeiten. Datum, Hashes, manuelle Sync IDs, Haltbarkeitsdauern, Datensatzsperren, ... .... und dann nen gutes Fehler-Handling wenn der Datenbank-Eintrag plötzlich neuer ist, als die eigene Änderung.

    Wichtige ist, ob Deine Clients gleichzeitig aktiv sein können, wie Du dann Daten ggfalls pushed... oder ob es ähnlich wie ne Cloud funktioniert und "eigentlich" nur ein Client gerade aktiv ist... und klar kannst Du nen Server bauen, der kann auch in CoreData seine Daten ablegen... aber dann musst Du Dich um den ganzen Server-Krams auch noch kümmern, dafür gibt es eigentlich ja schon hochentwickelte Datenbank-Server... wieviele Clienten wird es geben ist eine andere wichtige Frage wenn es gleichzeitigen Zugriff geben soll... da hängt davon ab, wie Dein Datenbank-Server skaliert sein muss....

    Also, ohne zu wissen, wie genau der Zugriff übers Netz aussieht, würde ich Dir sicherheitshalber ne dicke Oracle Datenbank empfehlen... die skaliert auch bis mehrere 1000 Zugriffe pro Sekunde gut hoch... ist nur vielleicht ne sehr große Kanone für kleine Spatzen ;)

    Lucas: Core Data lässt sich doch sicherlich auch in Distributed Objects einpacken.

    Ja, lässt es sich, Kapitel 11 in Marcus Zarras CoreData Buch

    Volker
  • Vielen Dank für die Antworten.

    Gibt es denn ein Framework für die Versionierung? So wies es Core Data in einer dokumentbasierten Applikation macht.
    Dann müsste ich mich ja nur um das Synchronisieren kümmern, was viel Zeit ersparen würde.
    Hier stellt sich mir auch die Frage, ob es hier von den Dokumenten abhängt oder es eine Core Data Funktionalität ist.

    Es ist eine Software, die ca. 20 Clients haben wird. Ein bis zwei OS X Applikationen zum verwalten von Aufträgen und einige iOS Geräte, die auf die Aufträge zugreifen müssen und diese abarbeiten.

    Man könnte auch einen JBoss nehmen und alles über einen Web Service abarbeiten, jedoch steige ich jetzt in Objektive-C ein und bin von dem Möglichkeiten von Core Data und den Bindings sehr begeistert und würde dies möglichst nutzen, damit ich mir viel Zeit ersparen könnte.

    Der Ansatz mit den Distributed Objects klingt sehr interessant.
    Dann könnte man eine Server Applikation erstellen, die für die Persistenz der Objekte verantwortlich ist und auf jedem Client eine Schicht zur lokalen Bearbeitung erstellen, welche mit der Serverapplikation synchronisiert wird.
    Könnte das im groben klappen, oder übersehe ich da etwas?

    Das Core Data Buch von Marcus Zarras scheint ja eine Art Bibel zu sein!?
    Gibt es auch ein deutsches Pendant, oder sollte man sich die englische Variante zulegen?
  • Moin,

    Versionierung passiert mit CoreData in der Art, wie Du das benötigst nicht. CoreData und Versions (Funktion vom OS für u.a. NSDocument und NSPersistentDocument) funktioniert mehr ode rminder nicht wirklich toll mit NSPersistentDocument... Problem ist, dass die UI entladne udn wieder geladen werden müsste, wenn ein eine andere Version aktiviert wird.

    Du willst prüfen, ob sich Datensätze geändert haben... bzw. musst auf dem Server vor/beim update von Daten halt sehen, ob jemand anderes zwischenzeitlich geupdated hat. Das geht über zB Zeitstempel und per Hand. Bindings kannst Du auch ohne CoreData verwenden. Du kannst zB Daten vom Server als JSON erhalten, und dann in einen ArrayController füttern.

    Wenn Du die DistributedObjects verfolgst, musst Du auf jeden Fall einen Mac im Netz haben, der von Deinen Clients erfasst werdne kann. Und DU musst dann nen Server schreiben, der auch parallele Anfragen zügig bearbeitet. Wenn Du gerad emit Objective-C anfängst... würde ich Dir das nicht empfehlen.

    Zeit sparst Du Dir, wenn Du eine etablierte Lösung verwendest, nicht, wenn Du Dich versuchst in CoreData einzuarbeiten und das ins Netz zu bringen für ne verteilte Anwendung... CoreData ist für einen Single-User uU schon schwierig genug, vor allem wenn es performant sein soll und dabei aber auch mal größere Datenmengen verwalten muss.

    Zarra: In Englisch.

    Volker
  • CD unterstützt schon Versionierung. Um das aber für die eigenen Zwecke zu verwenden, muss man letztlich einen Incremental-Store programmieren, was ohne Erfahrung sehr schwierig ist, da sich Apple beharrlich weigertweigerte, irgendwas zu liefern, was man Dokumentation nennen könnte. Aber man bekommt es so mit viel Gehirnschmalz hin.

    Soweit ich weiß, ich habe es selbst nicht gelesen, ist das Networking im Zarra unzureichend besprochen.

    CD basiert auf dem Gedanken von Dokumenten, die geöffnet, {geändert, gespeichert,} geschlossen werden. Um das anders hinzubekommen, muss man kräftig investieren. Es stellt sich da die Frage, ob es für eine bestimmte Anwendung lohnend ist. Immerhin kann man daran denken, clientseitig einfach Objekte zu entnehmen und gegebenenfalls zu sperren. Hängt stark von der Anwendung ab.
    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"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Oh, ich sehe gerade: Sie schreiben auch etwas zu Predicates und raten davon ab, das überhaupt anzufassen. Dazu kann ich nur sagen: Jaaaaa

    Das ist dermaßen kaputt gebaut von Apple, dass man gar nicht herausfinden kann, ob man es vollständig implementiert hat. Völlige Scheiße, wenn man bedenkt, dass semantisch völlig gleiche Prädikate je nach Herkunft komplett unterschiedlich gebaut werden.
    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"?
  • Ich habe mir jetzt das Core Data und Incrementel Store Guide angeschaut. Leider steht nichts zur internen Versionierung drin.

    Dann habe ich eine dokumentbasierte App erstellt und mir die dafür erstellte Core Data SQL Datei angeschaut. Dort gibt es ein Feld Z_OPT mit dem gekennzeichnet wird, ob eine Änderung vorgenommen wurde.

    Leider wird dort nicht abgespeichert, welche Änderung vorgenommen wurde. Von daher die Frage, wo speichert die dokumentbasierte App mit Core Date die Daten ab, um Revert To ... Funktionalität zu gewährleisten?
  • 1. Es ist eine gute Idee, in die SQL-DB zu schauen. Auch jetzt noch findet sich dort "Doku", die mal jemand bei Apple schreiben sollte.

    2. Es wird zu jedem Objekt ein Zähler als Version mitgeführt. Mehr nicht. So eine Art Journaling, wie du es erwartest, gibt es nicht im Standardstore. Aber du kannst es dir ja selbst schreiben. ;-)

    3. Es ist auch die Frage, ob das überhaupt sinnvoll ist. Die Änderungen im Ergebnis kannst du dir ja anschauen. Und was hast du davon? Konfliktlösung funktioniert so nicht. Ich kenne da die ein oder andere Applikation, die das einfach nicht einsehen will. Wenn du einen Konflikt hast, entscheide dich für A oder B. Aber versuche niemals, nie, auf keinen Fall etwas anderes. Mal abgesehen davon, dass bei Relationships das mit der Konfliktlösung so eine Sache ist, wenn es um Referenzen auf neue Objekte geht. Viel Spaß!

    4. Letztlich geht so etwas einigermaßen erträglich nur zentral.

    PS.: Ich kenne keinen Anwendungsfall für Objective-Cloud. Echt nicht.
    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"?
  • Auf das schreiben des Journalings läuft es wohl hinaus. Das habe ich mir versucht zu ersparen. Aber da wird wohl ein Incremental Store erstellt werden müssen. Soweit ich es jetzt verstanden habe, kann man diesen so einrichten, dass mehrere Applikationen auf die SQL-Datenbank sprich SQL-Lite Datei im Netzwerk, sowie über das Internet zugreifen können.

    Es ist zwingend notwendig, dass man sieht, wer welche Änderung wann vorgenommen hat. Damit man den Vorgang Schritt für Schritt nachvollziehen kann. Hier geht es nicht um das Programmatische, sondern um den Fall im Alltag, wenn ein Mitarbeiter z.B. etwas falsch eintragen oder überschreiben hat und man nicht weiss, wer es nun verbockt hat.

    Was meinst du jetzt mit Zentral?
  • Mach dir mal einen genauen Plan, was du dann damit machen willst. Und du wirst sehen, dass es dir nichts bringt. Vergiss es. "Ihre Eingabe konnte nicht übernommen werden, sie sie $woanders geändert wurde" ist das beste, was aus der Zahnpastetube herauskommt.
    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"?