Progetto pgDesigner 2/3

[md9327]

Quello che hai fatto và bene, unico dubbio: è possibile che nessuno utilizzi parametri?
POINT, per esempio, come per postgresql, accetta due valori (non ricordo se int o float), e il terzo parametro di pgTypeItem può essere usato per descrivere in maniera schematica come deve essere dichiarato il tipo, magari evidenziando i dati opzionali. Ti ricordo comunque che questo al momento viene usato solo nei tooltip, a meno che la tua idea di gestirlo nelle form alla fine venga applicata. Se dai un'occhio alle altre righe, vedrai che questo terzo dato è valorizzato.

Comunque, appena posso provvedo ad integrare il pezzo che hai inviato nel programma.

Thanks! :-)

[ccc]

Il fatto è che da come l'avevo capita io, i parametri erano quelli che si usano nelle CREATE TABLE... tipo:

CREATE TABLE ... nome CHAR(50) ...

insomma, in questo esempio il parametro che intendevo io sarebbe 50. Se è così, no, i tipi geometrici di MySQL non hanno parametri. Ma forse ho capito male? Perchè nella tua risposta mi sembra che ti riferisci ai parametri nel momento in cui crei il singolo oggetto, cioè appunto:

INSERT INTO .. (punto) VALUES (POINT(100 100))

Se ti riferisci a QUESTI parametri li posso inserire, però l'idea che ti avevo esposto non funziona più, perchè non c'entra con il contenuto del campo MySQLLength...

[md9327]

No, per parametri intendo quelli che definisci durante l'impostazione del tipo:

esempio:

Codice: [Seleziona]

xyz CHAR(50)

dove, appunto, 50 è il parametro, inteso come valore di tipo Integer, ovvero, la stringa Type conterrebbe:

Codice: [Seleziona]

"(n)"

tra le due parentesi obbligatorie, "n" è un valore che deve essere passato per definire la dimensione del tipo CHAR().

Tutto qui, il discorso è più semplice di quello che ho maldestramente descritto nei precedenti post.

Comunque, ripeto, se dai un'occhiata alle altri definizioni, scoprirai che in fondo si tratta solo di descrivere la sintassi che deve essere applicata a quel tipo, null'altro... Se vedi nella documentazione ufficiale, vedrai che il discorso è identico, dopo inizialmente viene discritta la sintassi, con tutte le possibili varianti, poi sotto vengono descritti tutti gli elementi, il loro significato, e il loro uso sintattico.

Per chiarire meglio il concetto, prendo una delle righe del codice come esempio:

Codice: [Seleziona]

ME.AddDatatype(pgTypeItem.Create("CHAR", "C", "[(l)]", "", "", "", "", "Fixed-length character string"))

"CHAR" è il nome del tipo (usata poi nell'edit dei campi);
"C" identifica in modo generico quali tipi tratta (C=Character)
"[(l)]" dice il formato, comprese le varianti, che deve essere usato per la scrittura del tipo: in questo caso le parentesi quadre indicano che la sintassi che racchiudono è opzionale (ovvero si può scrivere anche solo CHAR), mentre le parentesi tonde indicano che se il tipo viene dichiarato di una certa lunghezza, la dimensione deve essere inclusa tra le due parentesi tonde, infine "l" stà ad indicare che l'unico dato che può essere passato a CHAR è un numero (l=lunghezza). Ovviamente "l" è un'etichetta che ho applicato io, ma non ha molta importanza, potrebbe anche essere nominata "n".
Poi ci sono alcune stringhe vuote, che corrispondono ad altrettanti dati da passare a pgTypeItem, ma per "CHAR" non sono valorizzati.
L'ultima stringa contiene una descrizione sommaria del tipo "CHAR", ovvero che tipo di dati definisce e magari quale dimensione di memoria occupa (es, nel caso di Integer, potrebbe essere 8Bit).

Spero che ora sia riuscito a descrivere in maniera più chiara.

Riguardo "POINT", questo tipo potrebbe essere definito con due parametr, es. x e y; in questo caso il terzo valore da passare a pgTypeItem sarà:

"[(x,y)]"

oppure:

"[(x[,y])]"

nel caso sia permesso passargli solo il primo, e il secondo è opzionale...

[md9327]

BUILD: 645

Modifiche:
- corretti alcuni metodi nei driver MySQL e SQLite
- corrette alcuni metodi per la lettura e la creazione dei database SQLite;
- corrette alcuni metodi per la lettura e la scrittura dei file progetto per MySQL e SQLite
- alcune modifiche e correzioni nelle classi relative alle procedure di import/export
- al momento non è possibile determinare le relazioni per MySQL e SQLite
- al momento non è possibile determinare il valore per Check da database MySQL
- al momento non è possibile determinare le impostazioni di Unsigned, ZeroFill e Binary da database MySQL
- alcune modifiche nelle finestre di edit per Campi e Indici

Attenzione:
- le modifiche effettuate rendono illegibili i precedenti file progetto.

[ccc]

Ah, allora avevo capito... ma in fase di creazione del campo, non ci sono parametri. Un campo geometrico ha lunghezza variabile e non c'è modo di influenzare questo fattore. Tra l'altro io ne ho fatto un uso abbastanza banale e non ci capisco molto, ma se uno usa questi tipi ad alti livelli è meglio che usi Postgresql, perchè MySQL fa dei calcoli abbastanza limitati.

Purtroppo ho avuto meno tempo di quello che credevo ma non ti sto paccando, la mia proposta di codice arriverà presto!

[md9327]

Non c'è problema... tanto non ti pago lo stesso... :-)

[md9327]

Trovato un bel problemino!

Codice: [Seleziona]

SELECT specific_name
     , routine_catalog
     , routine_schema
     , routine_name
     , routine_type
     , dtd_identifier
     , routine_body
     , routine_definition
     , external_name
     , external_language
     , parameter_style
     , is_deterministic
     , sql_data_access
     , sql_path
     , security_type
     , created
     , last_altered
     , sql_mode
     , routine_comment
     , definer
  FROM information_schema.routines;

La select serve per estrarre tutte le informazioni relative ad una FUNCTION o una PROCEDURE da MySQL.
Eseguendo il comando sql da qualsiasi client per MySQL, ritorna correttamente tutti i dati, ma lo stesso comando eseguito tramite le funzioni di Gambas, con risultato ritornato in un Result object, non dà gli stessi risultati; nel particolare, il campo "routine_definition" che dovrebbe contenere la definzione sql della funzione mysql, in Gambas dà come risultato una stringa vuota, per cui in pgDesigner non è possibile gestire questo dato.
Analizzando la cosa ho notato che MySQL definisce questo campo come tipo "longtext", e Gambas come tipo String. La cosa sembrerebbe non comportare problemi, ma a quanto pare Gambas agisce in modo anomalo; la cosa strana è che anche il campo "sql_mode" è dello stesso tipo, ma non presenta lo stesso problema.
Il tipo "longtext", a quanto pare, MySQL lo usa per stringhe di testo piuttosto grandi, e potrebbe anche creare problemi di conversione se questo tipo contiene oltre la dimensione massima supportata da gambas per i suoi oggetti String; ma nei miei test, al momento non ho valori così grandi, per cui il comportamento mi pare alquanto anomalo.

Proverò a comunicare questa cosa anche al team di Gambas, ma se qualcuno ha qualche idea me lo faccia sapere.

[md9327]

Oltre a chiedere lumi a Benoit, ho fatto ulteriori prove e letto anche un pò di doc dal sito ufficiale.
In effetti, nella doc, negli esempi di connessione a MySQL, si consiglia (o dichiara? non ho ben capito...) di creare un modulo ad-hoc (invece di una classe? Bho?).
Nei miei test, ho infatti creato un piccolo modulo, dove ho fatto un pò di prove di connessione e utilizzo di MySQL, e le stesse query hanno funzionato come dovevano, ritornando tutti i dati che mi aspettavo, e in modo completo.
A questo punto, dopo aver letto la nota presente nella doc, ho provato testardamente a creare invece una piccola classe, derivata sempre da Connection, limitata a solo alcune funzionalità di quelle presenti in pgDesigner; a quanto pare la cosa continua a funzionare correttamente...
Il mio dubbio, che ho espresso anche nella mail a Benoit, è che ci sia un qualche problema nella classe Connection, che si presenta quando viene utilizzata come classe base per ulteriori oggetti; il problema, però, si identifica solo su un certo tipo di informazione (longtext) e solo con MySQL.
In PostgreSQL di test ne sono stati effettuati molti, e da circa due anni da quando è nato pgDesigner, senza problemi di questo tipo; in quanto a SQLite, le uniche sue limitazioni finora, sono il fatto di non essere un verso server, e di non possedere funzionalità attive per determinare in modo non arzigogolato le informazioni contenute nel file di database.

Bè, la cosa mi ha costretto a rivedere molta della logica degli oggetti che ho utilizzato in pgDesigner2, per cui toccherà lavorarci un pò su...

[ccc]

Quanto tempo che non scrivo qui...
Hai provato a usare SHOW CREATE FUNCTION nomefunzione / SHOW CREATE PROCEDURE nomeprocedura per ottenere la definizione SQL? Forse è una soluzione molto "sporca", ma io te lo dico, poi giudicherai tu...
Altra cosa, hai provato a cambiare i flag della connessione? (connessione compressa per esempio) Non so come funzioni in Gambas, se vuoi ti mando un esempio in Php, suppongo sia molto simile..

[md9327]

Invia pure, provo a vedere se mi viene qualche idea.

In realtà ho scoperto che esiste un problema con il diver MySQL di Gambas2, in quanto ora ho creato una classe che gestisce la connessione, e utilizzandola da un semplice programma di test tutto funziona, ma se la chiamo dalle funzioni di pgDesigner, ritorna tutto tranne il campo incriminato. Sembra come se esistesse un qualche problema nella gestione dinamica della memoria, per cui si perde qualcosa nel tragitto; e la cosa mi stà facendo imbestialire non poco... Questo finora è l'unico problema che mi impedisce di andare avanti, perchè mi stà facendo perdere tempo.
Ora, insieme alla riscrittura della logica di connessione, ho implementato una sorta di gestione, che mi ritorna una struttura dati da una query; in questo modo apro e chiudo la connessione ogni volta che eseguo una query, e questo mi permette di manipolare i dati senza tenere per forza aperta la connessione. L'oggetto Result resta valido solo con connessione aperta, e se viene chiusa, l'oggetto Result diventa invalido, per cui inutilizzabile...
Nonostante questa modifica, il risultato non cambia; già inserendo una PRINT del campo appena dopo la lettura, il valore che ritorna è NULL.

Il tuo suggerimento di usare quella sintassi brutale potrebbe essere valido, ma và un pò fuori della logica del programma. Sia per PostgreSQL che er SQLite, rilevo le info direttamente dal database, con query mirate. QUel tipo di sintassi potrebbe cambiare risultato nel tempo, dipendentemente dalla versione, per cui vorrei evitare di utilizzarla.

Ora che ci penso, anche l'idea della connessione flaggata, non credo risolva il problema, che penso più legato ad un problema interno Gambas. Ad ogni proverò anche questa strada.

Ho provato ad inviare un paio di mail a Benoit, ma ancora non avuto risposte...

[ccc]

Beh, se vuoi provare in Php si fa così:

Codice: [Seleziona]

$con = mysqli_init();

//options to set
$con->options(MYSQLI_OPT_CONNECT_TIMEOUT, TIMEOUT);
$con->options(MYSQLI_READ_DEFAULT_FILE,	OPTIONS_FILE);
$con->options(MYSQLI_READ_DEFAULT_GROUP, OPTIONS_GROUP);
$con->options(MYSQLI_OPT_LOCAL_INFILE, false);

// options to set (flags)
if (USE_COMPRESSION)
	$flags = MYSQLI_CLIENT_COMPRESS;
else
	$flags = 0;

// connection
@$con->real_connect(HOST, USER, PASS, 'mysql', PORT, SOCK, $flags);

Spero che la sintassi sia simile in tutti i linguaggi. mysqli_init() restituisce un oggetto connection. In Php conviene usare quella funzione invece di $con = new mysqli() perchè altrimenti non puoi... ehm... non mi ricordo cosa non puoi fare, ma ci deve essere una qualche funzione o parametro che non funziona.

Un altro suggerimento veramente idiota: hai provato a cambiare l'ordine dei campi nella SELECT o a usare degli alias? Non dovrebbe cambiare nulla, ma chissà... io quando non capisco un bug provo anche le soluzioni più stupide, e ti posso testimoniare che una volta su mille funziona. :-)

[md9327]

Ti ringrazio per il codice, uso anche io php, ma in Gambas non esiste un parametro del genere, almeno per quanto ne sò...
Ad ogni modo, riguardo i tentativi, il problema non è farli, infatti ho capito che il problema è solo nella librery di Gambas, e solo riguardo MySQL, e molto probabilmente c'è qualcosa che crea problemi in una situazione dinamica, come ho scritto nel precedente post.
Inoltre la cosa coinvolge esclusivamente i campi di tipo "longtext", e questo mi fà pensare che proprio per la natura altamente dinamica di questo tipo di campo, possa incidere nel problema riscontrato.
In tutti i casi, gli altri campi vengono letti correttamente, ad indicare proprio che è presente qualcosa che si incasina solo con i longtext.
In postgresql, come del resto anche in Oracle e altri dbms, esistono i VARCHAR, tipi di campo a dimensione variabile, che però gambas comprende molto bene, e non ho riscontrato finora problemi nella lettura.
Riguardo ai longtext di mysql, ho notato che Gambas ne definisce una lunghezza di circa 500Kb, sia che contengano dati, sia che siano vuoti. E' probabile che la dimensione (il valore a dir la verità è un numero abbastanza anomalo, puoi provare con l'oggetto Result...) sia rispondente alla realtà, ovvero alla dimensione realmente stabilita da Mysql, ma non l'ho riscontrata nella doc ufficiale.
Questa cosa però mi fà pensare ad un'altro problema, anch'esso non riscontrabile dalla doc, ovvero qual'è la dimensione massima di un'oggetto String in Gambas. Se mettiamo il caso di avere un longtext completamente pieno, e di volerlo caricare in una String di Gambas, ci si riesce a farlo? Oppure tocca inventarsi qualche algoritmo di lettura? A quanto ne sò nell'oggetto Field di gambas, le stringhe sono contenute in un'oggetto interno di tipo String, sarà vero?

Stò pensando di analizzare il codice sorgente di Gambas, per vedere se trovo qualche problema. Il codice in C non è un problema, in quanto è il mio linguaggio primario, ma non essendoci doc a rigurdo la cosa sarà un pò dolorosa...
Speriamo di trovare qualcosa...

Ad ogni modo, in contemporanea, stò sistemando anche il codice di pgDesigner, per cui non mi sono fermato a questo problema...

[ccc]

Anche in MySQL c'è il VARCHAR, che non ha limiti di lunghezza (il limite è quello dettato dalla lunghezza massima delle righe, che è 65535). Strano che Gambas fissi il LONGTEXT a 500 bytes, non credo che MySQL faccia una cosa del genere...
Lo stesso bug si riscontra con i LONGBLOB?

[md9327]

Forse ho scritto male: sono circa 500Kbyte, ovvero mezzo mega!

Riguardo a Gambas, vede il campo NON come un blog (altrimenti c'è una classe specifica) ma come String.
In effetti, seppur longtext sia da considerare un tipo BLOB, è anche vero che contiene testo, per cui mi pare giusta la conversione.
Il bello è che nel codice sorgente, questo tipo di campi sembra essere trattato come BLOB, ma poi, non si sà perchè, Gambas restituisce un tipo 9 (String).
Ma, come ho già scritto, il problema non è la diretta conversione del campo, tanto è vero che in un semplice test sembra funzionare, bensì il comportamento anomalo in un'applicazione più complessa, e quindi di maggiori dimensioni.
Ormai le ho provate tutte, e più di verificarne il comportamento, controllando direttamente l'oggetto Result, non sò che altro provare.
Io sono convinto che il problema risieda su qualche anomalia in memoria, ma non riesco a trovare punti nel codice sorgente che mi possano aiutare ad indentificare dove...
La query è sicuramente corretta, l'oggetto si comporta come deve (test minimo), per cui il problema è in gambas. Se avessi scritto due procedure diverse, con comportamenti diversi, sicuramente sarebbe colpa di qualcosa nel mio codice, ma non è così. Gli elementi sono gli stessi, ma il corpo è diverso, per cui diversa gestione in memoria...
I longblob non mi interessano, perchè nel repository del database mysql non vengono usati da nessuna parte, e poi non sono oggetto, o fanno parte, dello scopo di pgDesigner. Se creo un progetto con questi elementi, questi vengono creati correttamente nel db, anche perchè non passo per oggetti Gambas, e uso solo il metodo Exec() dell'oggetto Database. Inoltre, anche questo tipo di dato passa per strade diverse nel codice sorgente, per cui è probabile che si comporti in egual modo; ma, ad ogni modo, non lo utilizzo perchè non esistono campi di quel tipo nelle mie query.

Mi piacerebbe che Benoit rispondesse alle mie email, ma finora nulla...

Ti ringrazio moltissimo per l'aiuto, anche se non se ne esce...! :amici:

[ccc]

Capisco. E' passato un po' di tempo, sei riuscito a risolvere il problema?