CoreData et BDD sur serveur distant!

elf · novembre 2006

Salut,

Je voulais savoir si l'un de vous avais de l'experience en CoreData. Est-ce possible d'utiliser une base de données distante comme source pour CoreData? (Un fichier sql ou xml (ça dépend du type de CoreData que je choisis) sur un serveur http) (Cette BDD serais éditée par un logiciel admin)

Merci d'avance,
elf

AliGator · novembre 2006

Sans être expert en CoreData (je n'y ai quasiment pas touché), il me semble qu'il a son propre format, et les seuls formats vers lesquels il exporte doivent être propriétaire et le XML, sachant que pour le XML c'est un format XML bien à lui (tu ne peux pas préciser comment formatter le XML, il organise ses données de façon bien particulières avec des IDREF un peu partout, et tout... Et j'imagine que pour l'importation c'est la même chose.

Donc à mon avis il faut le faire soi même.
J'avais fait une petite appli avec uniquement des bindings et CoreData (but = sans une ligne de code), mais je voulais pouvoir lire des fichiers XML (à un format donné) et exporter ma base en XML (en suivant ce même format) : j'ai été obligé de taper un petit bout de code pour gérer le chargement et la sauvegarde de ma "base" (ce sont les seules lignes de code de cette appli d'ailleurs).

En même temps pour le peu de lignes de code que ça prend en général...

System · novembre 2006

Pas moyen, CoreData ne reconnaà®t que les URL de type file.

Chacha · novembre 2006

dans 1163700154:

Pas moyen, CoreData ne reconnaà®t que les URL de type file.

ça y est, j'ai retrouvé un endroit dans la doc qui en parle :
Core Data Programming Guide > Core Data Basis > Persistent Stores

For example-even if the initial implementation is able to fetch records only from the local file system-if an application makes no assumptions about where it gets its data from, then if at some later stage support is added for a new type of remote persistent store, it should be able to use this new type with no code revisions.

+
Chacha

System · novembre 2006

Si je le sais, c'est que j'avais justement essayé de créer un persistent store à partir d'une url non fichier: j'ai juste eu droit à un beau message d'erreur me priant de bien vouloir utiliser des url de type file.

Mais c'est une tendance qu'on peut voir dans Tiger: les URLs ont largement pris le pas sur les fichiers (à part pour ce qui touche aux bundles), justement pour permettre à terme de faire abstraction de l'endroit où elle seront stockées réellement les données.

ClicCool · novembre 2006

On pourrait pas imaginer de truander cette limitation ?

Avec par exemple une Url pointant sur un "fichier de données" observé et gérer par un daemon, ou simplement une autre partie du code, capable d'envoyer comme contenu suposé du "fichier" le résultat d'une requète sur une URL distante ?

Voire même un "fichier de données" directement exécutable qui ferait le boulot (quitte à causer en douce avec l'appli pour savoir que renvoyer).

OK c'est tiré par les cheveux mais p-e réalisable non ?

[EDIT] ou un vrai fichier mis à jour avec le contenu de requètes ?
Bon, OK j'ai toujours été un doux rêveur.

AliGator · novembre 2006

A mon avis pas forcément besoin de faire un daemon si tu veux faire un truc comme ça.
Moi je ferais plutôt un truc genre pipe UNIX. Conjointement avec la commande "curl" qui récupère les données d'un serveur quand on lui donne une URL.

Tu peux essayer si tu veux : tu lances un terminal et tu tapes "mkfifo tempFifo" pour créer la FIFO (tuyau), puis "curl www.google.fr >tempFifo" (commande bloquante tant que tu n'ouvres pas tempFifo en lecture). A ce moment tempFifo (le tuyau) est encore vide, non rempli. Mais dès qu'on va demander de lire le contenu de tempFifo, donc par exemple demander de lire 5 octets, la FIFO va toute seule demander à sa source, donc curl, de lui envoyer 5 octets (enfin c'est pas tout à fait comme ça que ça marche mais symboliquement en gros c'est ça)
Donc tout en laissant la commande "curl www.google.fr >tempFifo", bloquée, tu ouvres une autre fenêtre terminal, et tu tapes "cat tempFifo", ce qui va avoir pour effet d'ouvrir le 'fichier' tempFifo, lire son contenu, et te l'afficher, puis refermer le fichier. Au moment de l'étape "lire le contenu" c'est là que curl remplira la fifo réellement. A l'étape "fermeture du fichier" la FIFO sera fermée en lecture et du coup la commande "curl" de l'autre fenêtre terminal rendra la main.

Mais bon sinon à quoi bon créer ce genre d'outil ou faire ce genre de petite astuce avec curl+ une fifo, quand tu peux le contourner simplement, en récupérant le contenu à une URL distante donnée, pour l'écrire dans un fichier local temporaire, puis lire de ce fichier, puis supprimer le fichier temporaire ? un stringWithContentsOfUrl, un writeToFile vers un fichier temporaire, et basta, non ?

ClicCool · novembre 2006

Ben oui, merci Ali, y'a donc des solutions plus ou moins simples, mais réalisables.

Pourraient-elles permettre donc de tromper la limitation aux file-url ?
Et donc permettre un core data sur BDD sur serveur distant ?

elf · novembre 2006

La méthode d'écrire dans un fichier à partire d'une URL à l'air interessante. Mais comment faire pour faire attendre le chargement de la BDD CoreData par le programme pendant qu'elle s'update?

Le seul défaut de cette méthode est un énorme temps de chargement pour le programme...

System · novembre 2006

Le seul défaut de cette méthode est que tu vas faire de la bidouille sur une boite noire qui ne te demandera pas la permission si jamais elle doit être modifiée.

elf · novembre 2006

Hm, je doute que ils changent quelque chose aussi fondamental que l'emplacement de la BDD sur le disque...

M'enfin, c'est le seul moyen, non? (J'veux dire, avec les truc a ali et tout si la "boite noir" va être changée ça crée le même 'blêm!)

elf · novembre 2006

Hm, si je met ça dans le main.m? ça va fonctionner et être appelé avant le chargement de la BDD?

mais en ce cas, comment pui-je faire pour mettre un écran de chargement pendant le chargement?

CoreData et BDD sur serveur distant!

Réponses