MacAppStore et PostGreSQL
Rocou
Membre
Bonjour,
Jusqu'à présent toutes les applications Mac que j'ai développées utilisent PostGreSQL.
C'est pour qu'elles soient multi-utilisateurs.
Comment faire pour distribuer une telle application sur le Store? C'est possible?
Sinon que me conseilleriez-vous?
Jusqu'à présent toutes les applications Mac que j'ai développées utilisent PostGreSQL.
C'est pour qu'elles soient multi-utilisateurs.
Comment faire pour distribuer une telle application sur le Store? C'est possible?
Sinon que me conseilleriez-vous?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Si l'application est destinée à tourner sur MacOSXServer c'est transparent puisque PostGreSQL y est pré-installé.
Sur un MacOSX standard il faudra sans doute guider l'utilisateur pour installer un serveur PostGreSQL sur son poste, par exemple ça
De plus l'application doit être autonome, il est il me semble interdit de dire d'aller chercher des paquets ailleurs.
ça veut dire que l'application devra embarquer sa propre installation de PostgreSQL et démarrer son service comme un helper au besoin.
C'est faisable mais c'est pas simple.
Wow! Merci pour ta réponse.
Il me vient une autre idée. Est-il possible ("légalement" c'est à dire selon les CGV d'Apple) de proposer une version mono-utilisateur sur le store (donc utilisation de Core Data) avec un lien, une incitation a venir télécharger la version multi-utilisateur sur mon site?
Super ton lien! Merci!
Je ne pense pas.
Mais quand tu parles de multi utilisateur, tu parle de mode client / server ?
(un doute me prends, t'es pas le développeur de la suite cogilog ??)
Pas permis.
Non mais client depuis les débuts
C'est d'ailleurs cette suite qui m'a donnée l'idée de baser tous mes développements sur PostGreSQL.
Zut.
OK, par ce que cette suite fait un usage des plus immondes de PostgreSQL, j'espère que tu ne t'es pas trop inspiré de leurs habitudes de merde (limitations basées sur Bonjour, base de données collé là où il ne faut pas, utilisation d'une socket TCP et non UNIX pour le poste local, pas d'ouverture TCP en random sur les ports...).
Bref, cet outil fait son job mais c'est un recueil de très mauvaise intégration système...
A vrai dire, tout ce tu me dis est du charabia pour moi.
Ce qui m'agace chez Cogilog, c'est que le logiciel a la main sur Postgresql. A chaque mise à jour de la base, je dois modifier le fichier pg_hba.conf pour avoir accès à mes propres bases. Je ne peux pas en outre, installer la version que je souhaite car toute mise à jour d'un logiciel de la suite écrase tout.
Par ailleurs, pas moyen pour l'admin de déconnecter un utilisateur qui a "oublié" de quitter le logiciel avant de partir en vacance. Impossible alors de faire une mise à jour.
Mais comme tu le dis, l'outil fait son job, je n'ai jamais rencontré le moindre problème sur 10 postes clients, un serveur sous OSX Server et quelques portables qui accèdent aux données à distance. 5 sociétés gérées en simultané.
Sinon je créé mes bases "à la main" et j'y accède via un framework cocoa.
En gros, il ne devrait pas y avoir une base PostgreSQL pour toutes les applications mais bien une par application.
Le bon sens d'une intégration PostgreSQL dans une application Cocoa voudrait que les binaires PostgreSQL soient embarqué dans l'application ainsi que sa configuration.
L'application Server en Cocoa lançant la base PostgreSQL sur un port non standard (voire un port ouvert dynamiquement par le système et annoncé par Bonjour selon les cas) lors d'une utilisation en réseau. Pour une utilisation locale uniquement, aucun port TCP n'est censé être ouvert, il faudrait passer par des socket Unix locales pour éviter ainsi tout usage inutile de port TCP et exposition inutiles.
Le fait que cogilog prenne la main sur la base et foute la merde à chaque update est le pourquoi il faut tout ça, cogilog est mal codé et fait de la merde, si un jour son process de MAJ change de version de PostgreSQL et décide pour une raison X ou Y de vider la base (par ce qu'il est censé être seul dessus) c'est une perte totale de données... Et le fait est qu'on a pas accès aux sources pour vérifier ce que ce truc fait...
D'où mes recommandations de ne jamais partager un moteur de base sur OS X, toujours embarquer le sien et garder la main dessus.
C'est d'ailleurs la configuration d'OS X Server. Il y a une base PostgreSQL pour les services d'Apple, qui n'écoute qu'en socket UNIX et une base à destination de l'utilisateur qui écoute sur le réseau.
Oui cela m'est arrivé. Prudent, j'avais tout sauvegardé avant cette update majeure.
Mais je n'ai jamais réussi à installer plusieurs moteurs de base. Maintenant que j'ai un peu plus de temps, je vais creuser.
Merci pour les explications.
Tu as une démo dans OS X Server 2.2 pour Mountain Lion si tu l'installe.