PhilloPuntoIt

In un post su Oracle mi lamentavo della lunghezza massima dei nomi a 30 che questo DB impone. E qualcuno ha replicato se pensavo che dei nomi di 30 caratteri non fossero troppo lunghi...

A parte le considerazioni filosofiche mi è venuto in mente (e dato che www.larkware.com ne ha fatto la recensione proprio oggi mi è ritornato in mente di nuovo) un programmino che aiuta molto...

http://www.promptsql.com/

Costa poco (25 dollari), è fatto in svizzera e fa quello che deve fare, ovvero aggiungere un comodissimo Intellisense identico a quello di Visual Studio dentro ISqlw. Consigliato. Che poi mamma Microsoft ci possa far risparmiare sti 25 dollari probabilmente con mezza giornata di stagista e relativo checkin del codice è un altro discorso...

Sempre per il fatto di lavorare con Oracle mi sono scontrato con il fatto che il file .cs che viene generato automaticamente da Visual Studio non gestisce correttamente il caso in cui il dato sottostante sia un Guid su SQL Server (in cui il Guid è invece un tipo nativo) mentre su Oracle i campi Guid sono stati definiti come Char(36). Poi possiamo anche discutere di questa conversione (vi dico subito che sono ovviamente tutti campi chiave e quindi sotto ci sono delle motivazioni collegate alle performance), ma il problema è che il Dataset tipizzato mi espone dei Guid, dato che da Oracle mi arrivano delle stringhe vengono generate delle cast exception se non intervengo nel file .cs generato da Visual Studio (o da xsd.exe, che è la stessa cosa).

La modifica per far andare il .cs del dataset è roba da poco (mettere una if nelle property che tornano un Guid), però implica che si cambia del codice generato in automatico, cosa che non è mai bella.

E per la prima parte della ricetta viene comodo lo snippet di codice che vi passo (e che non è che si trovi in giro tanto documentato):

DataSet ds = new DataSet();
ds.ReadXmlSchema(...qui ci dovete mettere il nome del file .xsd relativo allo schema del Dataset...);
CodeNamespace cn = new CodeNamespace(...qui ci dovete mettere il namespace della classe che volete generare...);
CSharpCodeProvider cs = new CSharpCodeProvider();
ICodeGenerator cg = cs.CreateGenerator();
TypedDataSetGenerator.Generate(ds, cn, cg);

A questo punto nel vostro CodeDom avete esattamente la stessa classe che vi verrebbe generata dal tool xsd.exe (cosa che potete verificare chiamando la cg.GenerateCodeFromNamespace) e potete navigare tutto il vostro albero per cambiare/rimpiazzare/sistemare il codice del vostro Dataset tipizzato con quello che serve a voi. Qui poi vi scontrerete con il CodeDom, ma è un altro film...

Il secondo pezzo della ricetta consiste poi nell'automatizzare questo processo quando premete Control-Shift-Build in modo che se modifico il mio schema del dataset non debba ricordarmi tutte le volte di rigenerarlo (altrimenti diventa uguale al cambiare il .cs generato). Navigando in giro si trova un bell'articolo di Cazzulino che vi dice come usare l'extensibility di Visual Studio per fare in modo di fare il tutto in automatico, ma finisce che dovete scrivere tantissimo codice.

Io ho usato un modo molto ma molto più semplice:

1) Prendete tutti gli xsd dei Dataset, li mettete in una cartella comune (che fa sempre bene) e nelle proprietà ci togliete l'associazione MSDataSetGenerator come Custom Tool: 10 minuti di tempo con mastercard
2) Prendere il vostro codice e lo trasformate in un NewXsd.Exe che prende come parametri il nome del file xsd, il nome della classe da generare ed il nome del namespace: 1 ora di tempo con mastercard
3) Andate nelle proprietà del progetto ci aggiungete uno script di PreBuild che fa una cosa del genere
for %%a in (percorso dove stanno gli xsd\*.xsd) do percorso\NewXsd.exe %%a %%a.cs NomeDelNamespace
Altri 10 minuti con mastercard, di cui la metà spesi per capire come gestire i percorsi dato che prebuild e postbuild hanno convenzioni leggermente diverse
4) Avere tanti bei file con estensione .xsd.cs che inclusi nel progetto si compileranno belli come il sole e sapere che tutte le vostre build avranno dei dataset corretti e non vedrete più cast exception: non ha prezzo

Se nel vostro piccolo Exe mettere una semplice compare sulle date dei file il processo è praticamente inavvertibile come tempi.

Mai sottovalutare la potenza della vecchia command line!!!

Parliamo un po di Oracle. Ora non so quanti di voi abbiano a che fare quotidianamente con questa bestiaccia e quanti abbiano anche la fortuna (???) che il proprio prodotto debba lavorare sia con SQL Server che con Oracle. Io ho la bella fortunaccia di appartenere ad entrambe queste categorie.

E posso solennemente dire che nell'anno del signore 2005 avere ancora a che fare con un database che ha una limitazione a 30 (leggasi TRENTA) caratteri nei nomi di qualunque cosa (tabelle, colonne, indici, relazioni) è veramente scomodo.

Scusate lo sfogo, ma quando ci vuole ci vuole.

Se quello di prima era il primo post questo avrebbe dovuto essere il post zero...

Ovvero chi sono? Perchè dovrebbe interessarvi qualcosa leggere quello che dico?

Chi sono? Senza troppi titoli diciamo che mi occupo di informatica da molto, molto tempo. Se qualcuno si ricorda di FidoNet e l'indirizzo 2:332/9 gli dice qualcosa forse potrebbe anche quantificare il molto, io preferisco evitarlo (anche se avere avuto come primo modem un accoppiatore acustico a 300 baud è un altro brutto indizio).

In tutto questo percorso che è partito dall'Apple Basic ed è arrivato al C# passando per Clipper, TurboC, BorlandC++, Visual Basic ed almeno un altro paio di linguaggi proprietari che non conosce veramente nessuno mi sono sempre e comunque occupato di sviluppo (a parte un breve periodo in cui ho avuto un negozio), per arrivare al punto in cui sono ora in cui coordino un gruppetto di programmatori per sviluppare un completo prodotto di Workflow interamente sviluppato in C# all'interno di una grande ditta.

Quindi spero che vi potrete fidare, se comunque non siete d'accordo con me.... ditelo....

Ho anche un altro Blog che si trova a www.phillo.it e che parla di vita personale e di Golf (inteso come sport, non come macchina), appena riesco a configurare Imho o Blogjet per bloggare in contemporanea da entrambe le parti tutti i post tecnici saranno condivisi, penso invece di non ammorbarvi con quelli di Golf...

Blog2theMax - Il futuro VB e C#: LINQ, anonymous types, e altre diavolerie

A me quello che scrive Balena è sempre piaciuto, il suo libro su VB è stato veramente un classico che non invecchia e generalmente dice cose molto serie. Questo suo post invece non mi trova d’accordo, nel senso che su alcune cose la penso come lui ma per motivi completamente ed assolutamente differenti, mentre per altre sono completamente in disaccordo, quindi butto lì anche il mio parere su alcune cose nuove della PDC.

Late Binding vs. Strong Typing: su questo sono d’accordo con Francesco, ma non ritengo che il problema sia di performance ma di scarsissima leggibilità del codice. Se infatti posso arrivare a capire che

var i = 5;

sia ancora nell’ambito della leggibilità e che usarlo per variabili con uno scope molto piccolo sia assolutamente più comodo e rapido inizio ad avere dei grossissimi dubbi su

var j = SomeObscureAndHiddenFunction();

per cui capire quale possa essere il tipo di j diventa sostanzialmente impossibile.

Linq: qui invece siamo totalmente in disaccordo. Pur avendo qualche dubbio su quello che ho letto relativamente all’implementazione (ma dato che da qui alla disponibilità dell’oggetto passeranno ancora almeno 18 mesi non mi preoccupo più di tanto) ritengo che capire finalmente, a livello di linguaggio, che debba esistere uno strato comune ed integrato di persistenza dei dati sia la cosa migliore che si potesse fare. A prescindere della tecnologia che evolve e cambia (RDO, Ado, Ado.net, Jdbc, per arrivare ad NHybernate e tutti i vari ORM) il punto comune di tutto il mio lavoro degli ultimi 10–12 anni è sempre stato quello di “prendi i dati, facci qualcosa, persista i dati”. Se lo step centrale (facci qualcosa) è cambiato in maniera radicale nel corso del tempo (linguaggi 4GL – VB6 – C#) il primo e l’ultimo invece non hanno avuto cambiamenti sostanziali, scrivevo dell’SQL 12 anni fa per leggere e scrivere i dati, scrivo dell’SQL adesso. Ma il problema non è leggere e scrivere dell’SQL (dato che con Linq comunque il discorso non cambia), è che connettere questo SQL con il linguaggio ed il “facci qualcosa” era un lavoro sporco 12 anni fa ed adesso è sempre lo stesso identico lavoro sporco, più nascosto ed automatizzato da una sequela infinita di helper e di tool di programmazione, ma sempre quello. Linq è una speranza, che questo lavoro (che s’ha da fare, sia chiaro) invece di essere un lavoro sporco diventi un lavoro pulito, annegato nel linguaggio e quindi sostanzialmente più visibile ed elegante. Come ho detto è una speranza (perchè credo che la complessità intrinseca del “leggi i dati – scrivi i dati” non sparirà), ma onestamente se alla PDC avessero presentato l’ennesimo RecordSet glorificato mi sarei un po rotto le balle (qualcuno sa dirmi una differenza *di sostanza* tra RDO, Ado, Ado.Net 1.1 ed Ado.Net 2.0????).