Pubblicazione Progetto - Analisi Database Locali

[a.ceccoli]

Durante la pubblicazione di un progetto che contiene diversi database con molte tabelle,
buona parte del tempo viene impiegata nell'analisi dei database locali, cioè in quella parte della pubblicazione che si occupa di verificare che la struttura dei database sia allineata con quelle del progetto da pubblicare e prepararne gli script per l'aggiornamento.

Questo tempo aumenta ulteriormente se una o più applicazioni del progetto da pubblicare presentano il flag "Genera dati RTC" e sono composte da molte videate (..pannelli, campi..).

Per chi come noi lavora preparando delle release delle applicazioni a cadenza regolare sapendo di volta in volta quali sono le modifiche da apportare ai database non c'è la necessità di verificare la struttura dei database contenuti nell'applicazione.

Mi chiedo se si possa introdurre la possibilità di non effettuare l'analisi dei database locali durante il processo di pubblicazione, magari utilizzando il flag "Salta compilazione" che è già presente nelle proprietà dell'oggetto database.
Lo stesso flag è presente anche per le applicazioni e viene già utilizzato durante la pubblicazione per decidere quali applicazioni di un progetto mandare all'IDManager oppure no.

[g.lanzi]

Non ho capito bene la proposta, ma se ci sono delle modifiche da effettuare al database non è comunque necessario che IDManager svolta questa operazione?
Non è tanto per verificare la struttura del database e per informare l'utente della modifica, quantomeno non solo. Quell'analisi è necessaria a IDManager per sapere quali modifice apportare alla struttura del db per effettuare il deploy.

Mi puoi spiegare meglio?

[a.ceccoli]

E' certamente utile che IDManager verifichi se ci sono delle modifiche da effettuare al database.
In alcune situazioni però la pubblicazione delle modifiche al db tramite deploy non è sufficiente a garantire che applicazione e schema database siano coerenti.
Mi riferisco al fatto che a runtime l'applicazione ha la possibilità di collegarsi a database differenti tramite la proprietà defaultConnectionString.
Per questo non è sempre possibilie sapere a quale e a quanti database si dovrà collegare l'applicazione e di conseguenza "dove" applicare le modifiche al database.
In questi casi è necessario creare gli script di aggiornamento per ogni database "alla vecchia maniera" e applicarli dove ce ne è bisogno.

La modifica che propongo riguarda la possibilità di non effettuare l'analisi dei database locali non solo perchè si è certi che non verrà applicata(per i motivi descritti sopra)
ma soprattutto per evitare i lunghi tempi di attesa.
Accade infatti che, nel caso di database di grandi dimensioni, l'analisi impieghi diversi minuti(preziosi) prima di giungere alla fase di invio delle modifiche all'IDManager.

Nella nostra realtà l'utilizzo della pubblicazione diventa improponibile considerando che uno dei database sui quali lavoriamo contiene più o meno 450 tabelle e 15000 campi.
Avendo l'RTC attivato ogni volta vengono ricreati anche i dati RTC....in una delle applicazioni del nostro progetto ci sono circa 200 videate ed 8000 campi di pannello...

L'IDManager è uno strumento molto valido per poter aggiornare da remoto le applicazioni sviluppate con inde senza dover avere accesso diretto al filesystem del server in cui è necessario pubblicare, che sia di produzione o di sviluppo.
In sostanza mi dispiace non poterlo utilizzare a causa del tempo che impiega una pubblicazione e visto che questi tempi sono imputabili ad attività che nella nostra realtà non sono applicabili.

Spero di essere stato un po' più chiaro.