PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 01/02/2017 16:45:25

jplaroche
Membre

suite de la discution pgAmind4 et fork pgAdmin3

lors d'une demande d'ouverture de de sujet , l'Admin m'a suggéré (plutôt dit de regarder avec prudence) le fork pgAdmin3 valide pour pgSQL 9.6.x

a) oui cela existe bien
b) avec bigsql mais pour windows
c) il y a un gti a disposition ...


enfin de compte la demande du Fork n'est pas appuyé par l'équipe de postgresql , mais accepté si il reste dans la licence.
Quand ont regarde l'ensemble des obligations pour l'install , il faut remonter (wxwidgets  et gtk )a 2.8 , pytnon ancienne version ... ect...,
on comprends mieux pourquoi ils ont lâché l'affaire , et pour moi le retro pédalage est trop coûteux.

dans un mail de conversation entre l'équipe du fork et postgresql ,  postgresql dit qu'il feront le nécessaire pour amélioré et plus, et ne soutiendront pas le fork .

alors à quand un ppa pgadmin4  ....


@bientôt de vous lire

ps(je ne vous donne pas l'adresse du git  croyez-moi trop de problèmes malgré que le GUI est encore un peu plus avancé a ce jour 2017-02-01)


Bonjour, Arrive de DB2  1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR

Hors ligne

#2 01/02/2017 19:41:50

rjuju
Administrateur

Re : suite de la discution pgAmind4 et fork pgAdmin3

Avez-vous également regardé ce fork (https://github.com/dimv36/pgadmin3 ) qui semble relativement actif ?

Hors ligne

#3 01/02/2017 22:17:30

gleu
Administrateur

Re : suite de la discution pgAmind4 et fork pgAdmin3

Juste un ajout. Il existe une version de pgAdmin III qui supporte la version 9.6. Il s'agit de la version 1.22.2.

Il existe ensuite différents forks (dont celui de bigsql), dont la durée de vie, à mon avis, sera très courte.

Hors ligne

#4 14/02/2017 20:10:44

jplaroche
Membre

Re : suite de la discution pgAmind4 et fork pgAdmin3

bonjour ,
la version 1.22.2
effectivement la version la version 1.22.2 fonctionne
mais elle creer a chaque demande une 9.5 par defaut


j'ai mis a jour la version 9.6.2  postgresql lui ne présente aucun problème


rappel pgsql 9.6.2 pgadmin4 1.2


pour la version pgadmin4
toujours les mêmes problèmes avec pgadmin4 

la maintenance ne fonctionne pasbeug style (creation job failed)  (sauf si vous ête en admin sudo)
 


mais ne remonte aucun résultat

pour que cela fonctionne ne pas exécuter avec l'onglet maintenance

solution  avec le script  passer par l'interface editor sql  idem que pour create table si dessus

VACUUM FULL VERBOSE  ;(full table)
VACUUM FULL VERBOSE  votre_table ;
pgsql 9.6 vacuum

dommage ça rends le pgadmin un peu étriqué     

une solution (avec dbeaver      logiciel communautaire )

j'ai essayer divers solutions pour le moment rien ne remplace pgadminIII et la version 4 n'est pas terminé . au 15/02/2017
d'autre part je crains la compatibilité ou dut moins je voudrais que ça colle 100% hors les base accès Universelle c'est du 95%  exemple charactere(3) devient bpchar(3) et cela me chagrine car je me dit que la représentativité n'est pas exacte .... ou 90% dans certains logiciels exemple lors de la création de tables.

je suis tatillon avec la BD car j'étais architecte depuis 1980 alors comme je suis un papy j'ai des exigences dut à la responsabilité tant en maintenance quand faisabilité ainsi que fiabilité.
j'ai fais une étude de plus d'un an pour choisir une BD autre que DB2 AS400  et mon choix c'est porté sur postgresql qui pour moi représente un gage de respect des normes SQL et de sa fiabilité ainsi que sa portabilité.

Dernière modification par jplaroche (15/02/2017 10:59:54)


Bonjour, Arrive de DB2  1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR

Hors ligne

#5 19/03/2017 08:36:41

jplaroche
Membre

Re : suite de la discution pgAmind4 et fork pgAdmin3

postgresql 9.6.2
version 4 1.3
le vacuum fonctionne.

# DATA
         pg_dump     --format custom -a                              --encoding utf8 --host 127.1.1 --port 5432 --username postgres CGIFCH  > $CGIFCH_DATA
# SCHEMA
         pg_dump     --format custom --section pre-data  --section post-data   --encoding utf8 --host 127.1.1 --port 5432 --username postgres CGIFCH  > $CGIFCH_SCHEMA

puis

# recharge et creation des tables et leurs definitions 
        pg_restore      --host localhost --port 5432 --username postgres   --dbname CGIFCH   $CGIFCH_SCHEMA
# recharge les données
        pg_restore   -a --host localhost --port 5432 --username postgres   --dbname CGIFCH   $CGIFCH_DATA

la catastrophe plus de schéma ????

j'ai essayé à la main

-- TABLE: "FC0CLI"
-- COPY "FC0CLI"  FROM '/home/soleil/AS400/DEF_SQL/FC0CLI.csv' WITH DELIMITER '|' QUOTE '}' csv ENCODING 'WINDOWS-1250';
-- DROP TABLE "FC0CLI"    ;
CREATE TABLE public."FC0CLI"
(
"C0CDEP"    character(3  ), -- CODE DEPARTEMENT
"C0NCLI"    numeric(6,00), -- N° CLIENT
CONSTRAINT "FC0CLI_pkey"   PRIMARY KEY ("C0NCLI")
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public."FC0CLI"
  OWNER TO postgres;

COMMENT ON TABLE public."FC0CLI"
IS 'CLIENT FACTURATION';
COMMENT ON COLUMN "FC0CLI"."C0CDEP"         IS 'CODE DEPARTEMENT';
COMMENT ON COLUMN "FC0CLI"."C0NCLI"         IS 'N° CLIENT';


strictement identique au pg_restore pas de schéma à l'affichage

pour avoir votre schéma il faut passer par la création de colonne ????

 
par contre en utilisant la création de colonne  l'affichage fonction et vous obtenez un script   mais faux  exemple   
   
COCDEP      character[]  length 3  info CODE DEPARTEMENT     donne  le script   "C0CDEP"    character(3  )[] ...... le script imprenable en sql si vous le conserver

résultat des améliorations mais aussi des beug supplémentaire  !!!!  c'était pourtant pas difficile de récupérer les définitions et de les ré-afficher



je lâche l'affaire et reviens en 9.5.6 avec pgadmin III   je stop l'évolution     je testerait maintenant à la fin de l'année et encore .....     Je n'avais rien mis en prod  je voulais être sur de la maintenance qui pour est aussi important que la création.  en plus pas de .deb ni ppa  alors ....

je crois que je vais me faire un outils médian qui permet de construire des tables....  et d'avoir un référentiel    alors je reprendrais   le cours  de Postgresql .   trop de souci pour géré l'architecture d'une base de donnée .   @bientôt


Bonjour, Arrive de DB2  1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR

Hors ligne

#6 19/03/2017 08:43:03

gleu
Administrateur

Re : suite de la discution pgAmind4 et fork pgAdmin3

Pour commencer, merci de créer une discussion par problème et non pas les entasser dans la même discussion.

Ensuite, je ne comprends pas grand chose à ce que vous dites.

strictement identique au pg_restore pas de schéma à l'affichage

Qu'est-ce que vous entendez par schéma ? Quant à l'affichage, je suppose que vous parlez de ce qu'affiche pgAdmin... avez-vous pensé à rafraichir le navigateur ?

pour avoir votre schéma il faut passer par la création de colonne ????

Une colonne n'a pas de schéma. Une table, une vue, une procédure stockée, oui. Mais pas une colonne. Du coup, je pense qu'on ne parle pas de la même schéma pour les schémas.

Concernant pgAdmin4, personnellement, je pense en effet qu'il faudra attendre bien un an pour qu'il se stabilise.

Hors ligne

#7 20/03/2017 08:44:48

jplaroche
Membre

Re : suite de la discution pgAmind4 et fork pgAdmin3

gleu a écrit :

Pour commencer, merci de créer une discussion par problème et non pas les entasser dans la même discussion.

Ensuite, je ne comprends pas grand chose à ce que vous dites.

strictement identique au pg_restore pas de schéma à l'affichage

Qu'est-ce que vous entendez par schéma ? Quant à l'affichage, je suppose que vous parlez de ce qu'affiche pgAdmin... avez-vous pensé à rafraichir le navigateur ?

pour avoir votre schéma il faut passer par la création de colonne ????

Une colonne n'a pas de schéma. Une table, une vue, une procédure stockée, oui. Mais pas une colonne. Du coup, je pense qu'on ne parle pas de la même schéma pour les schémas.

Concernant pgAdmin4, personnellement, je pense en effet qu'il faudra attendre bien un an pour qu'il se stabilise.

je pensais faire le suivi et je ne dois pas être le seul dans ce cas ..... et je m'attendais a un peu plus d'activité sur le sujet.


breff j'arrive de l'aS400  c'est vrais là il n'y a pas de problème . le schéma est vue comme une procédure stockée pour parler dans votre langage  mais le catalogue représente bien plus que çà

quand à la  définition type SQL     'puisque le mot schémas ne vous plaît pas '     d'une version à l'autre pour pgadmin4 varie beaucoup , je comprends bien que cela évolue mais quand on marque que c'est la meilleurs au monde ..... il faut faire en sorte au moins de donner l'équivalent  au départ et fonctionnel .
pour la définition d'une colonne : lorsqu'on ne retrouve pas  la même chose dans une procédure stockée ?????
j'ai plus de 40 ans de service je veux bien être un papy mais je sais me servir d'un PC depuis les année 85 mes premiers logiciels pour AMI association médecine international à titre gratuits....


un schémas:  Définition d'une Data Structure  (DDS)   ou procédure stockée de définition de table.  l'ensemble du mots schéma pour une table recouvre ce qui peut permettre de comprendre sa définition ses autorisations ect...
Dans l'exemple suivant le schéma catalogue  défini la table des clients facturation  est créé en même temps.

exemple raccourci ... pgadminIII  car je ne peut pas vous le fournir en pgadmin4 v1.3 venant d'une procédure stockée (sauf si vous passer par la création de colonnes ... ou la représentation de la procédure stockée n'est pas viable )  par contre fonctionnait en v1.2  allez-y comprendre quelques choses effectivement c'est un manière de pas avoir de beug que de supprimer les affichages .....

- Table: public."FC0CLI"

-- DROP TABLE public."FC0CLI";

CREATE TABLE public."FC0CLI"
(
  "C0CDEP" character(3), -- CODE DEPARTEMENT
  "C0NCLI" numeric(6,0) NOT NULL, -- N° CLIENT

  CONSTRAINT "FC0CLI_pkey" PRIMARY KEY ("C0NCLI")
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public."FC0CLI"
  OWNER TO postgres;
COMMENT ON TABLE public."FC0CLI"
  IS 'CLIENT FACTURATION';
COMMENT ON COLUMN public."FC0CLI"."C0CDEP" IS 'CODE DEPARTEMENT';

COMMENT ON COLUMN public."FC0CLI"."C0NCLI" IS 'N° CLIENT';


plus la peine de répondre je laisse tombé . de toute façon il n'y a pas de discussion sur ce sujet , soit les personnes sans foutes ou qu'ils ce sont tourné vers autre chose . ou qu'il n'y a aucun intérêt.

je vais résoudre mon problème autrement, dommage que Postgresql est accepté  cela , son image sans trouve ternie. Fournir un outil peu fiable de base .....

quand à l'usure de la version pgadmin4  si vous ne comprenez pas c'est sûrement que vous ne l'utilisez pas sinon vous auriez trouvé  mes problèmes tant il sont évident et rende l'utilisation impossible et surtout pas fiable.

merci d'avoir pris le temps de lire.

Dernière modification par jplaroche (20/03/2017 09:27:52)


Bonjour, Arrive de DB2  1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR

Hors ligne

#8 20/03/2017 13:58:02

gleu
Administrateur

Re : suite de la discution pgAmind4 et fork pgAdmin3

Ce n'est pas que le mot schéma ne me plaît pas, c'est qu'il faut qu'on parle de la même chose. Il me semble logique que, pour parler de PostgreSQL, on utilise la terminologie PostgreSQL. Et sans vouloir être insultant, pour pouvoir vous répondre, il faut comprendre en premier lieu le problème. Vos phrases ne sont pas des phrases. Ça manque de ponctuation, ça manque de cohérence... je suis désolé, j'aimerais bien vous aider, mais je ne comprends rien à vos messages.

Enfin, concernant pgAdmin4, personnellement, je ne l'utilise pas. Je ne connais aucun client qui l'utilisent actuellement car trop récent et pas assez stable. J'ai utilisé pgAdmin3 pendant un bon moment, principalement parce que je faisais partie de l'équipe de développement. Mais dans ma vie professionnelle, je n'utilise que psql. C'est extrêmement rare que j'utilise pgAdmin, et généralement il s'agit de pgAdmin pour les clients qui n'utilisent que Windows (là où psql est difficilement utilisable).

Hors ligne

#9 20/03/2017 21:45:27

jplaroche
Membre

Re : suite de la discution pgAmind4 et fork pgAdmin3

gleu a écrit :

Ce n'est pas que le mot schéma ne me plaît pas, c'est qu'il faut qu'on parle de la même chose. Il me semble logique que, pour parler de PostgreSQL, on utilise la terminologie PostgreSQL. Et sans vouloir être insultant, pour pouvoir vous répondre, il faut comprendre en premier lieu le problème. Vos phrases ne sont pas des phrases. Ça manque de ponctuation, ça manque de cohérence... je suis désolé, j'aimerais bien vous aider, mais je ne comprends rien à vos messages.

Enfin, concernant pgAdmin4, personnellement, je ne l'utilise pas. Je ne connais aucun client qui l'utilisent actuellement car trop récent et pas assez stable. J'ai utilisé pgAdmin3 pendant un bon moment, principalement parce que je faisais partie de l'équipe de développement. Mais dans ma vie professionnelle, je n'utilise que psql. C'est extrêmement rare que j'utilise pgAdmin, et généralement il s'agit de pgAdmin pour les clients qui n'utilisent que Windows (là où psql est difficilement utilisable).

bonjour,
moi j'utilise pgadmin parce que :
j'ai besoin de comprendre pour faire des migrations de base de donnée DB2 AS400  et PostgreSql .
bien-sur j'utilise la documentation de PostgreSql , pour travailler et pour générer avec les formats mise à disposition du catalogue.

synoptique de traitement :
envoyer sous format csv de puis l'as400 (simple)
envoyer la procédure identique à une création faite par PostgreSql  afin d'automatisé cette migration et transferts de données .(simple )

puis je fais une extraction avec ECPG  de postgresql sous format XML .
puis je prépare mes librairies  (génération automatique de code  ECPG ) de tel manière que lorsque les programmes les utilises, le partage (1)OPDP soit actif au sein du process . D’où un gain très important lors du développement et en maintenance .

exemple:
Je reprends les programmes qui font du CGI sur AS400 en RPGILE(langage natif du 400), et les récris  puisque j'ai fait les LIBc++  je me retrouve à faire du CGI en mode LG4 le BUT, et la tranquillité d'utiliser les tables d'une façon uniforme. pourquoi le CGI parce-qu’en plus d'être portable , aujourd'hui avec le (2)websocket on peu faire du temps réel.

les résultats sont surprenant tant en rapidité , ainsi que pour la sécurité (voir rollback et accès ainsi que la tenu d'enregistrement avec le websocket)
les méthodes étant validé le service Informatique et le DBA , ils prennent actes et tout rentre dans les process à suivre pour le développement .

voilà pourquoi je m'inquiète:
vouloir une évolution constante afin de bénéficier des améliorations ( sur l'as400 cet une obligation ce qui permet d'avoir aucun métro de retard).

De plus  le DBA lui regarde avec la vue pgadmin , et moi je regarde avec les procédures mise à disposition par PostgreSql et pgadmin .  Jusqu'à présent il y avait une cohérence. Maintenant en 9.6.2 et pgadmin4 v1.3 ce n'est plus le cas.

je ne cherche pas à avoir raison.   je vous fourni la raison des problèmes .

je ne demande pas une solution , mais simplement si quelqu'un est partie sur une autre solution je serais preneur, ou pour partager.  (enfin dommage que personne n'est intéressé)
d’où la définition de data structure que je pense devoir développer afin de répondre au DBA, et au service informatique . 

@bientôt

ps peut-être suis-je plus clair.
(1)OPDP:  partage des process(fonction), des objet(field), des data(donnée), dans un même espace  donc les process et Objets ne sont définit qu'une  seul fois pour l'ensemble du projet.

(2) WEBSOCKET : solution validé par l'ensemble des acteurs Informatique et les grandes Industries, janvier 2016.

http://forums.postgresql.fr/viewtopic.php?id=3323


Bonjour, Arrive de DB2  1978--à ce JOUR
pratique ECPG depuis 2013-- à ce JOUR

Hors ligne

Pied de page des forums