Programmazione Python > Database

PostgreSQL cercasi aiuto!

(1/2) > >>

PyPeppe:
Qualcuno esperto di PostgreSQL è disposto ad aiutarmi?
Mi serve aiuto per installazione e configurazione PostgreSQL 12 da binario, tutto tramite codice Python 3 per successivo utilizzo di SQLAlchemy.
Grazie infinite.

RicPol:
sì ma per quale sistema operativo?
e poi ti serve un'installazione "seria" (tipo server di produzione) o vuoi solo averlo sulla tua macchina per testare e lavorare per conto tuo?
e che vuol dire "tramite codice python"?

PyPeppe:
Windows 7 o superiore; su una sola macchina, nulla di "aziendale", però fatto bene.
Da codice Python intendo che, il file zip della distribuzione di PostgreSQL va con il pacchetto di file del software che sto scrivendo con Python; al primo avvio dell'eseguibile, se il codice non riscontra nessun Database PostgreSQL, provvede ad installare (unzippare) il file distribuzione PostgreSQL e tramite subprocess ad inizializzare server etc

RicPol:
Uhm... mah? Sei sicuro che è quello che vuoi fare?
Da quello che scrivi, mi sembra che tu voglia scrivere e distribuire un software mono-utente. Ma in genere i software mono-utente non usano Postgres... non ha molto senso. Di solito per questi vale la pena di usare Sqlite, o un altro database mono-utente.
Se invece stai scrivendo un'applicazione multi-utente, con un database server interrogato da numerosi client su una rete, allora chiaramente va bene Postgres, ma il database va installato separatamente, sul server di rete, dall'amministratore della rete. Di sicuro non puoi pretendere di installare il database "al bisogno" quando installi un client su una postazione locale. Questo significherebbe che il tuo installer dovrebbe collegarsi al server, avere i privilegi dell'amministratore di rete... sarebbe una follia.

Comunque... se stai scrivendo un software mono-utente e per qualche ragione vuoi comunque avere postgres, installato sulla macchina dell'utente... allora comunque tieni conto che avrai qualche problema aggiuntivo, una volta installata tutta la baracca.
Per esempio, postgres è un processo demone che deve essere in esecuzione, al momento di avviare il tuo programma python che lo deve usare. Quindi, o tu installi postgres come un processo che si avvia automaticamente all'avvio del computer (come si fa in genere): ma questa cosa è scontata su un server, ma sulla macchina personale del tuo utente mi sembra una cosa un po' violenta da fare. In pratica tu stai chiedendo al tuo utente di tenere sempre attivo postgres che gira in sottofondo, solo perché serve al tuo programma... mah, vedi tu... io una cosa del genere non la farei. Oppure, devi avviare il processo di postgres ogni volta che avvii il tuo programma, e chiuderlo ogni volta che chiudi il tuo programma. Questo si può fare, ma tipicamente richiede privilegi da amministratore: e questo concretamente significa che il tuo programma dovrà sempre essere eseguito in modalità da amministratore... e quindi ogni volta che l'utente lo avvia, Windows gli chiede la password da amministratore... e anche questa è una cosa che si può fare, per carità... ma capisci che l'utente potrebbe essere un po' spaventato...
Altro problema: di solito postgres si installa (su un server) sotto un utente ad-hoc... in pratica nel server esiste un utente "postgres" sempre connesso, e il processo di postgres appartiene a quell'utente. Ovviamente questo non potresti farlo facilmente nel caso di un'installazione "domestica" sulla macchina dell'utente. In pratica dovresti chiedere al tuo utente di loggarsi normalmente al computer, *e quindi* di loggare anche l'utente "postgres", e tenerlo loggato solo per far girare il tuo programma... mi sembra veramente troppo. Quindi finirai per installare postgres sotto l'utente "normale" che fa anche girare il tuo programma. Questo non comporta particolari problemi, considerando che comunque siamo in un ambiente mono-utente, e non ci sono problemi di litigarsi le risorse. Però tieni conto, per lo meno, che tutta la directory che contiene i dati di postgres sarà accessibile all'utente (perché gli appartiene!) e quindi potrebbe inavvertitamente cancellarla o manipolarla. In teoria questo problema ce l'avresti anche con Sqlite... ma capisci che il database Sqlite è un singolo file che puoi mettere nella stessa directory del programma, e all'utente non viene in mente di frugrarci dentro. Invece i dati di postgres sono una directory con decine di file dentro... magari un giorno l'utente non si ricorda più a che serve tutto questo, e decide di fare pulizia.

Insomma, in generale un'installazione di postgres in ambiente mono-utente non ha molto senso, almeno nel contesto di "programma per l'utente finale". Ovviamente invece installarsi postgres sulla propria macchina di sviluppo per testare il codice, questa è una buona idea senz'altro...

Comunque, ipotizzando che tu voglia comunque fare in questo modo... andiamo avanti...
Per quanto riguarda il processo di installazione in quanto tale... mah, qui ho degli altri dubbi. Non capisco perché deve essere un processo di installazione unico. Non puoi installare postgres separatamente (magari facendo uno script che aiuta l'utente), e poi il tuo programma? Anche perché, a rigore, dovresti distinguere i tre casi: primo caso, non esiste postgres; secondo, esiste postgres ma non ancora il database che serve al tuo programma; terzo caso, esiste già sia postgres sia il database (questo può succedere se l'utente installa e poi disinstalla il tuo programma, o in caso di aggiornamenti... va a sapere).
Inoltre, non avresti comunque il problema anche di installare Python stesso? Oppure vuoi provare una di quei sistemi tutto-in-un-exe... però vedi la cosa buffa, che tu paradossalmente avresti il tutto-in-un-exe per il tuo programma, *ma comuque* dovresti installare postgres separatamente... mentre se usassi banalmente Sqlite, potresti davvero far stare tutto insieme.

Detto tutto questo... mah... installare postgres in modalità "automatica", "silenziosa" o come la si vuole chiamare, non è un problema. L'installer di postgres può essere invocato dalla riga di comando con l'opzione "--mode unattended"... se la metti assieme a un altro po' di opzioni, puoi fare tutta l'installazione in un colpo solo senza chiedere niente all'utente. A questo punto, puoi farti uno script che esegue questa installazione... e se vuoi potrebbe essere pilotato da python con subprocess, perché no... anche se a dire il vero sarebbe più comodo fare qualcosa come un batch script, o un powershell...
A questo proposito, anzi... te lo devo dire: l'idea che sicuramente tu hai in mente, che il tuo programma si avvia e, se non trova il database, magicamente si installa postgres e tutto quanto senza che l'utente debba preoccuparsi di niente, è un'idea profondamente sbagliata. Se il tuo programma all'avvio non trova postgres, questo può essere per mille motivi... per esempio perché il processo di postgres è caduto o è stato interrotto per qualche ragione, o non è stato possibile avviarlo... va a sapere... E se ogni volta che il tuo programma non trova postgres se lo reinstalla allegramete, dopo un anno il tuo utente ha quindici installazioni di postgres sulla sua macchina. Secondo me sarebbe meglio che se il tuo programma non trova postgres, fa quello che fanno tutti i programmi che all'avvio non riescono a connettersi al database: si pianta e mostra un messaggio all'utente.
Comunque, riprendendo il discorso: tu puoi senz'altro farti uno script che installa postgres silenziosamente, e puoi farlo girare da python se vuoi. L'importante è che ti ricordi che comunque questo script di installazione deve pur sempre avere permessi da amministratore... quindi hai un problema ulteriore... o il tuo script python già in partenza è eseguito con privilegi da amministratore (ma allora devi spiegare all'utente di avviarlo come amministratore!), oppure con subprocess devi elevarti eseguendo "runas"... ma se esegui "runas", allora devi sapere la password dell'amministratore (ovvero devi chiederla in precedenza all'utente) ed essere pronto a fornirla all'utente con subprocess.communicate(). Si può fare, eh... nessun problema.

Per quanto riguarda lo script di installazione vero e proprio... ripeto, in sostanza si tratta di avviare l'installer di postgres con "--mode unattended" e qualche altro fronzolo... qui faccio prima a passarti due link, tanto questa è la cosa più facile...
https://www.postgresql.org/download/windows/
https://silentinstallhq.com/postgresql-12-silent-install-how-to-guide/
https://coderwall.com/p/r6nqrw/automated-postgresql-install-and-configuration-with-powershell

Dopo di che... mah... e usare Sqlite e non complicarsi la vita?

PyPeppe:

--- Citazione da: RicPol - Giugno 18, 2020, 23:42 ---Uhm... mah? Sei sicuro che è quello che vuoi fare?

[.......]

Dopo di che... mah... e usare Sqlite e non complicarsi la vita?

--- Termina citazione ---

Ti ringrazio per la risposta, molto esaustiva e per l'impegno dedicatomi.
Fondamentalmente hai inquadrato bene la situazione.
Il mio software, chiamiamolo applicazione desktop, dovrebbe funzionare su pc con sistema operativo windows; l'idea era proprio quella di installare PostgreSQL in maniera "silenziosa" la prima volta, istanziare un database con utenza e password "stabilite via codice" poiché dovrebbe essere usato solo dall'applicazione e poi ad ogni lancio dell'eseguibile avviare il server del database per il suo utilizzo. Ma ci sono molti punti stonati, come ben rilevato dalla tua analisi. Il primo, credo fondamentale, è quello che il pc su cui girerebbe l'applicazione è gestito da un amministratore e l'applicazione andrebbe usata da più utenti e non solo, ci sarebbe anche la possibilità che,più pc in lan possano usare l'applicativo (questo da valutare, non so se limitare l'uso ad un solo pc).
Se consideriamo valido il secondo sviluppo, sarebbe stato giusto installare il server PostgreSQL su un pc della lan e far girare l'applicativo sul resto dei pc, ma questo richiederebbe una gestione da parte dell'amministratore che al momento non è possibile, perché sto sviluppando questo software in maniera autonoma e per l'ausilio dei vari colleghi, chissà un giorno potrebbe essere apprezzato e passare ad uno step superiore!! Ma ad oggi deve girare su una macchina gestita da amministratore e ipotizzare un uso senza installazione.

Faccio un bel passo indietro..... questo software sostanzialmente deve gestire dei dati, un registro dati contente tra le altre cose anche dati di georeferenziazione e quindi dovrebbe "dialogare" con il software QGIS per mettere su cartografia questi dati. All'inizio ero orientato su Sqlite, poi mi sono fatto ingolosire da postgreSQL perché  "gestisce anche database ad oggetti, con il supporto per la nidificazione ed altro ancora" e per l'abbinamento PostgreSQL+PostGIS per la gestione dei dati spaziali..... ma senza far fronte a tutta questa problematica.

Alla luce della tua giusta analisi devo ricredermi sulla mia scelta e tornare a valutare l'ipotesi Sqlite, quindi orientarmi sull'abbinamento SQLite+Spatialite....
{cit.: SpatiaLite si basa sul DBMS SQLite che supporta sia le specifiche SQL che OGC-SFS (Open Geospatial Consortium – Simple Features Interface Standard). L’intero DB è contenuto in un unico file che può essere quindi agevolmente trasferito da un pc all’altro e che risulta compatibile con Windows, Linux, Unix e Mac. È totalmente gratuito ed open source; non richiede installazioni complesse, basta semplicemente scaricare l’applicativo dal sito www.gaia-gis.it/spatialite, decomprimere il file e lanciare l’applicativo GUI, Graphical User Interface ma, cosa ancor più importante, è perfettamente integrato in QuantumGIS tanto che è possibile creare tabelle, effettuare ricerche ed interrogazioni direttamente dalla piattaforma GIS tramite il plugin DB Manager. }

Devo vedere se riesco a far girare l'applicativo su pc impostati come sopra, ovvero avviabile/installabile la prima volta  da un singolo utente, magari su C in una cartella visibile in lan, per poi l'eseguibile essere visibile a tutti gli altri utenti, oppure, ogni utente si installa/avvia il proprio applicativo sulla propria utenza, ma questo deve puntare all'unico file del database sulla macchina (magari visibile anche in lan), installatovi la prima volta dal primo utente che ha lanciato l'applicazione. Insomma un casino!! ma non voglio scoraggiarmi.

Scusa il modo sbrigativo di esporre il tutto, ma ho dovuto fare in fretta, spero di averti reso l'idea. Grazie.

Navigazione

[0] Indice dei post

[#] Pagina successiva

Vai alla versione completa