Core Data - Speichern unter einem auswählbaren Ort und wieder laden.

    • Core Data - Speichern unter einem auswählbaren Ort und wieder laden.

      Hi,

      da mir gestern so gut geholfen wurde, würde ich gerne noch ein paar Fragen loswerden. Mir ist klar, dass Core Data keine Datenbank wie Sqlite ist aber besteht die Möglichkeit, die Daten in Core Data wieder einzulesen ? Jetzt mache ich dass gerade sehr unschön, indem ich Core Data als Sqlite speicher und dann wieder meine Attribute per ZIRGENDWAS einlesen lasse. Geht das nicht eleganter ? JSON habe ich mir mal angesehen ist aber doch auch nicht das wahre oder ?

      Für jeden Tipp wonach ich googlen soll oder etwas Code wäre ich dankbar.


      Ach und wenn ich gerade dabei bin. Kann man zusätzlich zur Store-Datei diese noch mal woanders speichern ? Mhh, ich glaube ich muss zeigen was ich meine weil ich mich komisch ausdrücke.

      Quellcode

      1. - (IBAction)CoreDataSpeicherunter:(id)sender {
      3. NSSavePanel *mySavePanel = [NSSavePanel savePanel];
      4. [mySavePanel setTitle:@"Datenbank speichern unter:"];
      5. if([mySavePanel runModal] == NSOKButton)
      6. {
      7. NSURL *myURL = [mySavePanel URL];
      8. NSURL *url = [myURL URLByAppendingPathComponent:@"storeBar.sqlite3"];
      10. if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:url options:nil error:nil])
      11. {
      12. NSError *error = nil;
      14. if (![[self managedObjectContext] commitEditing]) {
      15. NSLog(@"%@:%@ unable to commit editing before saving", [self class], NSStringFromSelector(_cmd));
      16. }
      18. if (![[self managedObjectContext] save:&error]) {
      19. [[NSApplication sharedApplication] presentError:error];
      20. }
      22. }
      24. }
      Alles anzeigen


      Vom Gefühl her ist da mächtig was falsch. Kann nur nicht sagen was. Muss dazu erwähnen, dass ich Objectiv-C gerade erst lerne aber meine kenntinsse in anderen Sprachen sagen mir, dass da was falsch sein könnte.

      Vielen Dank und ich hoffe, man kann verstehen was ich meine.

      Gruß

    • NeoNeT schrieb:

      Mir ist klar, dass Core Data keine Datenbank wie Sqlite ist

      Gut erkannt. :)

      NeoNeT schrieb:

      aber besteht die Möglichkeit, die Daten in Core Data wieder einzulesen ? Jetzt mache ich dass gerade sehr unschön, indem ich Core Data als Sqlite speicher und dann wieder meine Attribute per ZIRGENDWAS einlesen lasse.

      +ähm+
      Core Data ist keine Datenbank!
      Die Daten sind nach Öffnen der Anwendung automatisch geöffnet.
      Die richtige Frage ist: wie komme ich an die Objekte ran.
      Dazu hilft die Dokumentation
      Und bitte arbeite nach dem ersten Fetch mit Objektzeigern weiter. In jeder Ansicht ein neuer Fetch ist neben extremst zeitraubend und hardwarehungrig auch noch extremst sinnlos.

      NeoNeT schrieb:

      Ach und wenn ich gerade dabei bin. Kann man zusätzlich zur Store-Datei diese noch mal woanders speichern ?

      Klar. Das ergibt nur überhaupt keinen Sinn, da Core Data in seiner Standardkonfiguration immer den Store ausliest.
      «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

    • Ahh, jetzt verstehe ich ;-). Mein Problem war, dass Core Data immer wieder eine neue Datei angelegt hat. Und deswegen immer leer war. Glaube ich zumindest.

      Zum Speicher:

      Ich möchte gerne zwei Versionen haben. Eine mit einem Inhalt bei einem bestimmten Attribut und bei dem anderen soll der Inhalt leer bzw. ein andere sein.
      Ist das Blöd mit CoreData umzusetzen ? Doch lieber Datenbank nehmen ?


      Danke für die Antwort :)

    • NeoNeT schrieb:

      Ich möchte gerne zwei Versionen haben. Eine mit einem Inhalt bei einem bestimmten Attribut und bei dem anderen soll der Inhalt leer bzw. ein andere sein.
      Ist das Blöd mit CoreData umzusetzen ? Doch lieber Datenbank nehmen ?

      Der Ansatz klingt blöd. Wozu?
      «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

    • Weil ich CoreData wie eine Dantenbak behandel ;) Ich möchte einmal eine Information in der einen Datenbank und in der anderen diese eben nicht bzw. andere. Ich glaube, dass ich zum Speichern Sqlite nehmen muss und diese dann wieder einlese und in CoreData packe.

    • Macht immer noch keinen Sinn. Wozu soll das gut sein? Du kannst, wenn es unbedingt sein muss ja genauso gut ein Attribut anlegen anhand dessen Du zwischen den beiden Typen von Objekten unterscheidest. Also in dem Fall

      NSInteger type

      oder sowas. Type=0 sind dann die Objekte die du in die eine DB packen willst und Type=1 die anderen. Dann kannst Du sogar fast beliebig viele Typen definieren ohne Deinen Code ändern zu müssen.
      Wobei es wirklich keinen Sinn macht. Die Sqlite Datei hat dich bei CoreData überhaupt nicht zu interessieren. Wenn Du da auch nur drüber nachdenkst machst du schon was falsch. CoreData benutzt Sqlite (aber auch das nur wenn man es nicht ändert. Ist halt Default Einstellung) aber das war es dann auch schon.

      Gruß

      Claus
      2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

      Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

    • Ich muss mein Beispiel mal genauer aufzeigen.

      Der Inhalt ist der Nachname und die Mail-Adresse die ich nicht zeigen will auf anderen Mac's. Nur quasi meine "Datenbank" soll diesen Inhalt haben. Auf anderen Mac's soll diese eben nicht angezeigt werden. Und jeder der etwas Ahnung hat, könnte ja mit nem SQLviewer eben die Daten sich so ansehen . Deswegen geht die Lösung nicht mit dem Interger-Wert

      Aber Danke, die Antwort hat mir aber ein paar neue Ideen verschärft ;)

      Gruß

    • Wenn du die Daten speicherst können sie auch angezeigt werden. Ob das jetzt direkt über die SQLite Datenbank von Core Data geht oder über eine eigens von dir intern angelegte Datenbank ist wurscht.

      Da der Anwender die Daten aber vermutlich eh selbst eintragen wird, dürfte das egal sein.
      Es sei denn, du ziehst die Daten und Mailadressen aus dem Netz. Dann solltest du dir aber wesentlich mehr Gedanken um die verschlüsselte Übertragung machen.
      Aber: Wenn niemand diese Adressen je zu sehen bekommt, warum willst du sie dann abspeichern?
      «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

    • Daten wie Namen und Adressen werden NIEMALS ohne Verschlüsselung in einer Datenbank gespeichert. Sowas macht man einfach nicht.

      Und wenn Du sie verschlüsselst, dann nimm einfach zwei verschiedene Schlüssel. Der eine für Nachname und Adresse und der andere für den Rest. Dann lieferst du nur den zweiten SChlüssel mit aus und es ist total egal ob Name und Adresse mit in der DB stehen oder nicht.

      Gruß

      Claus
      2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

      Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

    • Thallius schrieb:

      Daten wie Namen und Adressen werden NIEMALS ohne Verschlüsselung in einer Datenbank gespeichert. Sowas macht man einfach nicht.

      Das kommt hinzu, doch nutzt es herzlich wenig, wenn der Übertragungsweg quasi im Klartext statt findet.

      Davon abgesehen: wozu Daten speichern, die man eh nicht braucht?
      «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

    • Thallius schrieb:

      Daten wie Namen und Adressen werden NIEMALS ohne Verschlüsselung in einer Datenbank gespeichert. Sowas macht man einfach nicht.

      Claus

      Ach, ja? Wie macht man das mit der Verschlüsselung mit Core Data denn?
      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"?

    • NeoNeT schrieb:

      Ich muss mein Beispiel mal genauer aufzeigen.

      Der Inhalt ist der Nachname und die Mail-Adresse die ich nicht zeigen will auf anderen Mac's. Nur quasi meine "Datenbank" soll diesen Inhalt haben. Auf anderen Mac's soll diese eben nicht angezeigt werden. Und jeder der etwas Ahnung hat, könnte ja mit nem SQLviewer eben die Daten sich so ansehen . Deswegen geht die Lösung nicht mit dem Interger-Wert

      Aber Danke, die Antwort hat mir aber ein paar neue Ideen verschärft ;)

      Gruß

      Du kannst unseren Secure Incremental Store verwenden, der die Daten verschlüsselt. Kostet allerdings.
      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"?