Newsgroup: it.comp.software.database
Titolo: Abilitare funzionalità MySQL 4.1 in MySQL 5

Ciao, con il MySQL 4.1 avevo interessanti funzionalità che mi
piacerebbe avere anche nella versione 5:
1. potevo definire un campo TEXT NOT NULL con DEFAULT VALUE '', in
questo modo, se avevo una tabella con cognome, nome e note
(quest'ultimo TEXT NOT NULL DEFALUT '') potevo scrivere query del tipo
INSERT INTO teballa (cognome, nome) VALUES ('pippo', 'pluto'). Con il
MySQL 5 non posso più farlo in quanto il TEXT non accetta un default
value.
2. se creavo una query tipo CREATE TABLE x (cognome char(50) not null,
nome char(50) not null, `data_nascita` date not null) il MySQL 4.1 in
automatico aggiungeva il default value: CREATE TABLE x (cognome
char(50) not null default '', nome char(50) not null default '',
data_nascita date not null default '0000-00-00'). con MySQL 5 questo
automatismo non c'è.
Dato che ho centinaia di pagine di query scritte con questo sistema, e
vorrei passare alla versione 5 di MySQL, prima di mettere mano a tutte
le pagine, speravo si potesse sistemare dalla configurazione di MySQL,
ma dalla documentazione non ho trovato niente a parte: il campo TEXT
non può avere un DEFAULT VALUE!!!. qualche idea?

 non può avere un DEFAULT VALUE!!!. qualche idea?
disabilita lo strict mode
http://tinyurl.com/84a7s

 disabilita lo strict modehttp://
tinyurl.com/84a7s
ciao, grazie per aver risposto. avevo già fatto questa prova. nello
specifico
nel file my.ini ho impostato sql_mode = '' e ho fatto riavviare il
servizio mysql
ma lo stesso per il campo TEXT non vuole un default value.

 qualche idea?
Si: bruciare al rogo e condannare all'inferno MySQL AB
Enrico
P.S. spero che Sun metta una grossa pezza a questo schifo di situazione

 P.S. spero che Sun metta una grossa pezza a questo schifo di situazione
La cosa che più mi fa incavolare è che la versione 4.1 funzionava
tanto bene. Sia per i TEXT che per i valori predefiniti automatici!
Utilizzo SQLyog per accedere ai DB e quando creo una tabella con il
mysql 4.1 non ho necessità di mettere i valori di default quando creo
le tabelle. Basta mettere "not null" ad esempio su un campo datetime e
il mysql sistema automaticamente gli assegna come campo di default
'0000-00-00 00:00:00". Non capisco perché dalla versione 5 in poi mi
tocca mettere valori predefiniti per forza. Sono io che dovrei
decidere se il mysql deve o non deve chiedermi per forza i valori
predefiniti! Ma che hanno combinato?

 predefiniti! Ma che hanno combinato?
Non conosco mysql 5 e non entro in merito al tuo problema, ma ad occhio mi
sembra questo il comportamento corretto.
Se un campo č NOT NULL, se non passi nulla lui *deve* dare errore.
Se poi un campo NOT NULL puň avere un valore predefito allora uno lo
specifica.

 tanto bene.
Forse non mi sono spiegato bene. Quando dico "Bruciare al rogo e
condannare all'inferno MySQL AB" lo dico perche` quei tizi hanno avuto
la pensata di _crearlo_ un coso del genere; e quando dico "Spero che Sun
metta una grossa pezza a questo schifo di situazione" intendo che spero
che chiuda MySQL AB, faccia internare nei recessi piu`oscuri dell'Arkham
Asylum[1] gli sviluppatori, e che vieti in maniera assoluta anche il
pronunciare il nome di quell'abominio che si ostinano a chiamare
database
Enrico
[1] 
http://it.wikipedia.org/wiki/Arkham_Asylum

 specifica.
Ok, non mi sono spiegato io. Fino alla versione 4.1 ogni campo
definito come not null aveva un suo valore predefinito assegnato
automaticamente se tu non lo assegnavi. Non metto in dubbio che a te
non piace quel sistema che a me faceva risparmiare tempo, per cui mi
chiedo come mai con le versioni successive non ci abbiano dato la
possibilità di scegliere se dare o non dare valori predefiniti ai
campi not null in fase di creazione della tabella (in questo modo
accontentavano te e me).

On 10 Mar, 22:54, Enrico 'Henryx' Bianchi

ehm... calma, io chiedevo come mai alcune funzioni che a me facevano
tanto comodo fossero state rimosse. Ora mi tocca rimanere alla
versione 4.1 in quanto sulle nuove versioni le cose che mi facevano
risparmiare tempo non ci sono. Fammi capire, tu cosa proponi come
alternativa non a pagamento?

 accontentavano te e me).
Quello che non ho capito è che a logica io definisco come NOT NULL i campi
chiave, e quelli che devono essere riempiti per forza dall'utente.
Tali campi sono pochi, diciamo qualche pseudo chiave e poco altro.
Non è che metto il campo QUANTITA' delle righe di un ordine come NOT NULL,
mentre invece metto come NOT NULL l'IDARTICOLO (che è FK).
In ogni caso le tabelle le creo tutte da SQL quindi non mi cambia nulla
scrivere es.
CHANGE_DATE DATE DEFAULT 'NOW' NOT NULL,

 alternativa non a pagamento?
Qualsiasi alternativa (sia essa a pagamento o no) risultera` sempre e
comunque ardua, in quanto tutti i veri RDBMS non permettono quelle
oscenita` che permette MySQL
Enrico

 automaticamente se tu non lo assegnavi. 
Piu` lo leggo e piu` non riesco a capire. A cosa cavolo serve un campo
NOT NULL che automaticamente ha un valore di default?
Enrico

 alternativa non a pagamento?
PostgreSQL, ad esempio?
ilSimo
-- 
now playing: 
Here Minkions
Here you got: Minkions
You can touch: Minkions
You can love: Minkions, Minkions' band!
                                Bulldozer - Minkions

 NOT NULL che automaticamente ha un valore di default?
Concordo... per di più aggiungerei che NON ha senso definire un campo 
NOT NULL e come default inserire una stringa vuota. Oppure definire NOT 
NULL una data e poi mettere come default tutti zeri. A questo punto 
metti "NOW" o un valore "logicamente" accettabile.
C'è anche da dire una cosa... Forse siamo molto abituati, e parlo di chi 
lavora con i tool standard di mysql, ad aspettare che i programmi 
completino il nostro lavoro. Ad esempio se con il tool delle Query 
decidi di creare una vista e scrivi la query che unisce più tabelle in 
maniera poco corretta, in fase di compilazione il programma converte ciò 
che è stato scritto nella forma più corretta. Un esempio pratico è la 
gestione dell'INNER JOIN. Se unisco più tabelle con:
"select tab1.*, tab2.* from tab1, tab2 where tab2.idtab1 = 
tab1.id
"
Il query browser me la traduce con l'INNER JOIN fregandosene della 
sintassi che ho scritto.
Ritornando al problema del NOT NULL credo che solo MySQL 4.x fa questa 
cosa dei default vuoti. O almeno me lo auguro perchè sono logicamente 
assurdi. O no?

 assurdi. O no?
Logicamente sono assurdi in quanto non hanno senso, tanto vale impostare
il campo a NULL e buona notte al secchio
Enrico

Enrico 'Henryx' Bianchi wrote:

mica tanto. il NULL e' un valore-non valore, e un campo che contiene una
stringa vuota e' diverso da un campo NULL...
o sbaglio?
ilSimo
-- 
now playing: 
"Suddenly I awoke. I must have fallen asleep under the oak,
where I used to sit and dream as a child
The dawn was soon to come, and the air was crisp and cold
Yet I felt warm
I remembered my strange dreams and knew I had the strength
and love in my heart to create something in my life.
The world was waiting I was reborn"
                                Candlemass - Dawn

 o sbaglio?
E' diverso, e proprio per questo non ha senso la gestione di mettere SEMPRE
un valore predefinito al null.
Al limite in estrazione lo si tratta come si vuole SELECT
COALESCE(secondo_nome,'').
Molto probabilmente il discorso del valore predefinito č stato fatto per
facilitare le maschere/elaborazioni, per evitare controlli se il campo č
Null del tipo:
Dim Data as date
If Not IsNull(campo_data) then
	Data=campo_data
	if Data<Data_odierna then ...
end if
Ma io preferisco far lavorare il codice e le select, piuttosto che
memorizzare dati a valori predefiniti non imputati.

 memorizzare dati a valori predefiniti non imputati.
ovvio, alla fine si va di preferenze/abitudini, pero' sul ha senso/non
hasenso mettere un valore predefinito invece che NULL dipende da caso a
casi, IMHO, ad esempio il classico campo "note", dove avere il campo vuoto
ti fa solo risparmiare un po' di COALESCE()...
poi sull'usare insieme NOT NULL e default, pare un po' strano anche a me :)
ilSimo
-- 
now playing: 
Retaliate
Decapitate - I love to see them bleed
Annihilate
I'm human insecticide
                                Annihilator - Human Insecticide

 ti fa solo risparmiare un po' di COALESCE()...
Boh, un campo note di norma non č un campo che viene elaborato o che, di
norma viene stampato o visualizzato. Per il primo problema, qualsiasi
report decente non stampa nulla se il campo č Null, nel secondo caso basta
farsi una funzione *generica* da utilizzare sempre per assegnare i valori
dei campi alle textbox, che controlla il null.
Anche perchč vedo molto piů complesso fare una funzione che ad esempio
faccia:
if isDate then
	if is 00/00/0000 then risultato=""
if isnumero then
	if is 0.00 then risultato =""
if is stringa then
	if is "" then risultato =""
Che una che fa:
myDate=NullDef(campo_data, Date)
myPrezzo=NullDef(campo_prezzo,0)
ecco la funzione che uso, consigliatami anche sul ng
Public Function NullDef(ByVal vntValue As Variant, Optional ByVal Default
As Variant) As Variant
    If IsNull(vntValue) Or IsEmpty(vntValue) Then
        If IsMissing(Default) Then
            NullDef = 0
        Else
            NullDef = Default
        End If
    Else
        NullDef = vntValue
    End If
End Function

 As Variant) As Variant
che pero' alla fine e' equivalente a dire che la data e' "00/00/0000" se il
campo e' null, o sbaglio? ;)
ilSimo
-- 
now playing: 
For I am the Bringer of War 
I am The Bearer Of The Black Sword
and my name will be known to all
Lord Elric of the Bright Empire of Melnibone
The Dragonlord
                                Domine - Dragonlord

 campo e' null, o sbaglio? ;)
Bhe io quando faccio scrivere una data in una casella di testo, se non c'è
scritto nulla la lascio vuota, altrimenti formatto la data inserita.
Immaginati di guardare una griglia di 100 righe o una maschera con diverse
txtData con scritto 00/00/0000, non è il massimo per l'utente :).
Quindi se devi fare la conversione considerando un valore come "" in
visualizzazione (valori diversi a seconda del tipo di dato), vedo molto
meno problematico lasciare il campo Null.
Poi anche io ho campi predefiniti, ma li gestisco dalle maschere.
Esempio se uno va a fare una fattura, si trova la data odierna
pre-riempita, ma la può cambiare.
Ma di certo se l'utente non la riempe non vado certo a sfruttare la DEFAULT
di SQL per prendere la data odierna, ma blocco il salvataggio prima.
Come ti ho detto dipende da che applicazioni uno fa e per chi sono.

 prima.
punti di vista, io preferisco avere il database il piu' coerente possibile e
vincolato di per se, e lasciare meno liberta' ai controlli lato
applicativo, per questo preferisco non affidarmi solo all'applicazione, se
possibile. certo e' una cosa che si valuta caso per caso.
ilSimo
-- 
now playing: Hans Zimmer - Spider Pig
Caught in the afterlife
I've gone too far
When sorrow sang softly and sweet
The air was filled with tears
Full of sadness and grief
When sorrow sang softly and sweet
                                Blind Guardian - When Sorrow Sang


Ragazzi voi parlate di VB6 ma il MySQL può essere utilizzato in tanti
modi. Se lavorate con PHP è mooooolto più semplice avere dei campi di
default sul not null in modo da scrivere mooolto meno codice. Comunque
sono punti di vista, ma il problema, ripeto è un altro. Se ognuno ha
il suo stile e il suo modo di vedere le cose, bastava solo che il
MySQL desse la possibilità nelle opzioni del file di configurazione di
impostare il comportamento del db secondo le proprie esigenze, mentre
ora non è possibile farlo e, chi ha iniziato e si è abituato a
programmare in un modo, ora se vuole passare al mysql 5 o superiori,
deve non solo cambiare metodo di scrittura del sorgente, ma riscrivere
molte applicazioni!!! Questo è inaccettabile!
Per quanto riguarda il PostgreSQL sinceramente dopo aver passato tanti
anni a programmare con VB5/VB6 e MySQL, con PHP e MySQL, con tutte le
applicazioni che ho scritto, passare a PostgreSQL mi costerebbe troppo
(se ci giochi puoi anche farlo, ma se ci lavori devi valutare tempi e
costi per passare ad un nuovo dbms e il 99% delle volte non è
fattibile). Poi non capisco queste valutazioni limite. Non ho detto
che MySQL non funziona, ma ho detto che dalla versione 5 in poi i
programmatori non hanno dato la possibilità di sfruttare alcune
caratteristiche della versione 4 e spero che con le future versioni ci
ripensino.


Insomma, alla fine nessuno mi ha dato una risposta accettabile
per risolvere il problema, questo vuol dire che questa volta i
programmatori del MySQL hanno cannato e mi toccherà rimanere
al 4.1 il più a lungo possibile. Quando dovrò passare per forza ad una
versione successiva mi toccherà riscrivere centinaia di pagine in PHP
e programmi in Visual Basic? Se non tornano sui loro passi e mi danno
la possibilità di configurarmi il MySQL a modo mio come con il 4.1...
grazie tante al MySQL!

 al 4.1 il più a lungo possibile
Cioe`, fammi capire, basi il tuo lavoro sul fatto che quelli di MySQL
hanno tolto una funzionalita` abominevole che e` facilmente replicabile
scrivendo un paio di istruzioni in piu` durante la creazione delle
tabelle? Mi dici dove e cosa sviluppi, cosi` mi tengo a debita distanza
dal tuo lavoro?
Enrico

 o sbaglio?
Non sbagli. Tieni pero` a mente una cosa fondamentale: il comportamento
di un campo NULL e` sempre certo. Su tutti i database che conosco, un
confronto su di un campo NULL e` sempre falso e, da quello che ho visto,
tutti i linguaggi di programmazione prevedono un metodo per gestirlo
correttamente. Usare un campo NOT NULL a cui poi si applica un default
non sensato (e.g. una stringa vuota), equivale a non aver compreso la
logica che sta dietro al funzionamento e alla progettazione delle basi
di dati (o almeno questo e` quello che penso)
Enrico

 molte applicazioni!!! Questo č inaccettabile!
Piu` leggo i tuoi interventi, piu` ritengo che tu non sia un
programmatore serio, ma un cacciavitaro. Inoltre stai basando tutto il
tuo discorso su di una funzionalita` non vera, che non faceva altro che
imitare un comportamento ottenibile semplicemente con una sintassi
standard dell'SQL. Vuoi una tabella con tutti campi NOT NULL a cui
associare un valore di default predefinito? Eccotela:
CREATE TABLE test (
  col1 INTEGER NOT NULL DEFAULT 0,
  col2 VARCHAR(10) NOT NULL DEFAULT '',
  col3 DATE NOT NULL DEFAULT '0000-00-00'
);
Funziona su qualsiasi database in qualsiasi versione
Enrico

Enrico 'Henryx' Bianchi wrote:

certo, sono d'accordo con te, come dicevo ad Andrea non e' che rifuggo i
NULL come la peste, ma a volte i default sensati possono esistere :)
ilSimo
-- 
now playing: 
Mirror Mirror on the wall
True hope lies beyond the coast
You're a damned kind can't you see
That the winds will change
                                Blind Guardian - Mirror Mirror

 NULL come la peste, ma a volte i default sensati possono esistere :)
Si, questo e` sacrosanto. Rileggendo cio` che ho scritto sembra quasi
che io reputi insensato l'uso dei default in qualsiasi caso. Non e`
cosi`, e me ne scuso se dal mio discorso si e` capito il contrario
Enrico

On 20 Mar, 00:52, Enrico 'Henryx' Bianchi

Chi ti ha insegnato le buone maniere, il Gabibbo? Ma fammi il piacere.
Se devi dare queste risposte evita, non mi servono. E' facile
offendere
su Internet, vero?

 Enrico
Più leggo le tue risposte e più capisco che sei un cretino.
Io chiedo una cosa e tu mi rispondi con un'altra. Se non sai leggere
non è colpa mia.
Comunque lascia perdere, non ho bisogno dell'aiuto di uno a cui la
famiglia non ha saputo insegnare le buone maniere.

 su Internet, vero?
Una persona che ragiona a questo modo l'offendo anche dal vivo sia esso
un mio collega, il mio capo o, addirittura, un cliente. Il tuo
comportamento e` quello di una persona a cui non interessa crescere
professionalmente (comportamento giustificabile in alcuni, pochi, casi,
ma deprecabile nel mare magnum degli altri casi). Quindi, piuttosto che
avere a che fare con persone che la pensano come te, preferisco di
gran lunga evitare sia di dare un'occhiata al tuo lavoro, sia di
lavorare con te
Enrico
P.S. ti faccio una domanda seria, in cui ti pregherei di non prendere in
considerazione il giudizio che ho dato su di te (o meglio, su tutti
quelli che la pensano come te) e sul tuo lavoro in questi miei ultimi
post, e a cui ti pregherei di rispondere in maniera altrettanto seria.
Che senso ha definire una colonna NOT NULL a cui vengono associati
*automaticamente* dei valori di DEFAULT?

On 28 Mar, 00:18, Enrico 'Henryx' Bianchi

Utilizzando valori di default sui NOT NULL risparmio molto tempo in
quanto,
per molte applicazioni, non è necessario verificare la differenza tra
NULL e
campo vuoto. Lo so che con la programmazione è possibile raggiungere
gli
stessi risultati, ma già che le funzionalità c'erano nel 4.1, non vedo
perché
dover perdere tempo ad aggiornare pagine scritte in PHP che
attualmente
funzionano benissimo. E' una questione di praticità e tempo, dove per
tempo
intendo ovviamente denaro. Ovvio comunque che se sei un puritano
della
programmazione, queste cose non puoi arrivare ad accettarle, e non
pretendo
che tu lo faccia, mi infastidisce solo il fatto che ho chiesto
un'informazione,
se era possibile attivare una funzionalità che a me serve. Bastava un
"non lo so"
oppure "non si può", non una lezione di informatica teorica, a quella
ci arrivo
da solo.

 campo vuoto.
Forse non hai capito il punto della domanda di Henryx.
Se un campo e` "pippo varchar(256) NOT NULL DEFAULT "pippo", 
automaticamente non potra` mai essere null, perche` se fai
insert into tab (pippo) values (NULL);
o
insert into tab (altrocampo) values (quelchee);
in ogni caso la colonna "pippo" vale "pippo". Che tu le assegni NULL o che 
non le assegni alcun valore, quella prende "pippo". Non puo` essere NULL, 
quindi non ha senso dichiararla NOT NULL.
E` chiaro adesso?
Dichiarala semplicemente
pippo varchar(256) DEFAULT "pippo"
ed hai lo stesso risultato.
Bye.

 se era possibile attivare una funzionalità che a me serve
I metodi tradizionali per ottenere quello che vuoi (e quello che vuoi
e`, orribile, a mio parere) te li ho detti anche io. E il bello e` che
devi solo modificare gli script di creazione delle tabelle
Enrico

 in ogni caso la colonna "pippo" vale "pippo".
In teoria e` cosi`, in pratica non sempre:
conto=# create table test(uno varchar(30) default 'pippo');
CREATE TABLE
conto=# insert into test values(1);
INSERT 0 1
conto=# select * from test;
 uno 
-----
 1
(1 row)
conto=# insert into test values(NULL);
INSERT 0 1
conto=# select * from test;
 uno 
-----
 1
 
(2 rows)
conto=# 
La differenza sta tutta nella logica di cio` che fai. A che senso avere
un campo che non accetta i NULL quando sai che non puoi averne?
Enrico
P.S. In tutto questo mi lascierebbe perplesso pero` una cosa: perche` ho
1 come valore in test? Io lo so so, e voi? ;)
P.P.S. il database e` PostgreSQL, un database vero ]:)

Mi arrendo. Non si grida a un sordo.
Almeno sapete se è possibile assegnare un valore di default ai campi
TEXT? Tipo: ...note NOT NULL DEFAULT ''... o ...note DEFAULT ''... o
quello che sia. Basta mi ci metta un valore predefinito non null se
non lo dichiaro esplicitamente nell'uso nella insert into.


Scusate ho sbagliato a scrivere:
...note TEXT NOT NULL DEFAULT ''... o ...note TEXT DEFAULT ''...