ZZ_Object

[maurizioim]

Buongiorno,

forse quanto sto per scrivere e' gia' in fase di aggiornamento; pero' la segnalazione riguarda la pubblicazione e l'aggiornamento dei dataase collegati all'applicazione che si va a pubblicare.

E' ovvio che si cerca di tenere allineati i database, ma a volte puo' capitare anche per errore del gestore del database che, ad esempio, qualche foreign key non sia memorizzata correttamente. Questo comporta che la pubblicazione del programma non possa essere eseguita perche' i database non sono tutti allineati; invece Idmanager dovrebbe lavorare per singolo database ed eventualmente solamente segnalare quelli non aggiornati in modo da riuscire, almeno, ad effettuare la pubblicazione del programma. Poi sara' cura di ognuno andare a verificare la struttura delle tabelle non aggiornate; cosi' e' troppo bloccante e costringe a staccare i database da aggiornare per potere pubblicare il programma.

Grazie, cordiali saluti.

[lucabaldini]

Se ho capito bene stai chiedendo di far sì che IDManager possa pubblicare una applicazione anche se il DB non è a posto.
Non mi sembra una idea corretta... se il DB non è a posto è molto probabile che l'applicazione non possa funzionare poiché il DB non verrebbe aggiornato e occorrerebbe metterlo a posto manualmente per far sì che tutto sia a posto. E questa cosa si complica se aggiorni più database che sono uguali ma non sono uguali poiché alcuni DB sono diversi tra loro.

Secondo me se uno o più dei tuoi DB viene maneggiato da terzi è meglio che pubblichi senza eseguire le modifiche ai database (ovvero disabilitando la spunta dei DB che In.de sente cambiati). In questo modo l'applicazione viene aggiornata e il DB no. A questo punto puoi aggiornare i DB manualmente.

In alternativa, devi far sì che "i terzi", quando modificano il DB lo facciano su tutti i database definiti in IDManager.

[maurizioim]

In pratica si, sarebbe che sia consentita la pubblicazione anche se non tutti i database sono aggiornati come struttura; poi sara' cura dell'utente allineare il database che gli compete.

Invece abbiamo un dubbio: da un'applicazione ricreo lo zz_object e, immagino, ne aggiorna la parte solo per le tabelle che sono presenti nell'applicazione; poi da un'altra applicazione ricreo lo zz_object sullo stesso database ma per altre tabelle. Quindi avrei piu' database dove non su tutti ho le stesse tabelle, perche' alcuni potrebbe avere una sola delle due applicazioni e quindi meno tabelle rispetto al DB che ha entrambe le applicazioni; in questo caso, quando viene pubblicata una delle due applicazioni, idmanager non andra' a controllare che tutti i database abbiano le stesse tabella ma controllera' solo le tabelle dell'applicazione.
Grazie.

[lucabaldini]

Credo che nel tuo caso molto specifico la soluzione sia usare IDManager solo per la parte applicativa e non modificare i DB direttamente ma farlo manualmente.
Queste operazioni "manuali/semi-automatiche" non possono essere gestite da un sistema automatico che, per sua natura, segue una procedura ben definita. Sarebbe come voler usare un pilota automatico di un aereo ma voler pilotare o muovere alcuni comandi, alcune volte e chiedere che il pilota automatico sia automatico... ma solo a volte... e non si lamenti se io muovo i comandi... Non potrà mai funzionare a dovere.

Per quanto riguarda il dubbio non ho capito... hai un database su cui buildi 2 DB differenti di diversi progetti? E lo fai ricreando solo la ZZ_OBJECT? Ogni volta che lo fai la ZZ_OBJECT viene svuotata e ripopolata con la nuova struttura... però il comando "ricrea ZZ_OBJECT" non opera sulla struttura del DB ma solo sulla ZZ_OBJECT... quindi mi aspetto che dopo la seconda "buildata" tu abbia le tabelle della prima compilazione ma la struttura ZZ_OBJECT della seconda... cosa che, se ho capito bene, non potrà mai funzionare correttamente.

Di sicuro IDManager non è in grado di gestire questo caso... IDManager prende il primo database dello stesso tipo presente nel progetto, ne legge la ZZ_OBJECT e calcola le differenze da applicare su tutti i database dello stesso tipo che, DEVONO essere tutti allineati alla stessa versione... Se non lo sono (perché qualche DB è in stato "strano") IDManager non sarà in grado di aggiornare il sistema.

In questo caso hai 2 alternative:
- non aggiornare mai i DB con In.de quando pubblichi
- "staccare" i DB che gestisci manualmente eliminandoli dalla configurazione dell'applicazione dentro ad IDManager... così IDManager non sa nemmeno che esistono e non li toccherà o interrogherà mai.

[maurizioim]

Si, abbiamo la casistica di piu' applicazioni che operano nello stesso database utilizzando tabelle diverse per ogni applicazioni.

Quindi puo' capitare che un database abbia tabelle di 2 o piu' progetti, mentre un altro database abbia tabelle di un solo progetto.

Questo perche' abbiamo applicazioni che condividono i dati, pero' ognuna gestisce direttamente solo alcune tabelle del database.

Grazie, cordiali saluti.

[lucabaldini]

In questo caso credo che IDManager non possa riuscire ad aggiornare lo schema quando il DB è "sharato" tra app differenti che richiedono schemi del database differente.

L'unica soluzione che mi viene in mente è gestire la modifica dello schema dei DB manualmente... gestendo con IDManager il solo aggiornamento dell'applicazione.

[maurizioim]

Infatti, ci siamo organizzati per effettuare gia' alcune operazioni di aggiornamento delle tabelle; "purtroppo", metto tra virgolette, abbiamo programmi programmi diversi tra loro come funzioni che eseguono, ma che hanno invece una parte della base dati in comune.

Grazie per tutte le indicazioni, cordiali saluti.