Pagina 2 di 5 primaprima 1 2 3 4 ... ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 48
  1. #11
    è vero però forse non hai notato l'utilizzo delle mie applicazioni:

    sono applicazioni che girano in locale o al massimo in LAN aziendali, dove la possibilità di avere query + potenti, versatili e complete giustifica anche un "rallentamento" (che comunque, si nota solo con db notevolmente carichi e sotto sforzo)

    inoltre anche dal punto di vista commerciale il fatto di non dover prendere una licenza si traduce in un sacco di rogne in - per me e quindi un costo minore dell'applicazione finita!

    o sbaglio?
    "durante i primi 5 miuti di pioggia nel bosco c'è ancora asciutto, poi quando smetterà di piovere nel bosco cadranno gocce per 5 minuti.....la natura ha un'ottima memoria..."

    http://www.kumbe.it

  2. #12
    tu devi prendere una licenza SOLO se non rispetti la licenza GPL

    e quello dipende da te

    se chiudi il codice sorgente crittandolo o codificandolo, in qualsiasi modo, senza dare i sorgenti, blocchi la licenza

    se loro vogliono farci modifiche devono poterlo fare, ma in realtà, hanno le conoscenze sufficenti per fare le modifiche?

    se tu rilasci un applicativo sotto GPL non è che è gratis...ma è modificabile dagli acquirenti e questi possono redistribuire le "proprie" modifiche, non possono vendere il tuo prodotto o darlo gratuitamente, di conseguenza, realmente, tu credi di correre questo rischio?
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  3. #13
    scusate..torno su di qualche post...in particolare il problema di mysql e mysqli ..ma sotto linux tutti questi problemi di compatibilità non ci sono? e non ci saranno nemmeno in futuro?
    "durante i primi 5 miuti di pioggia nel bosco c'è ancora asciutto, poi quando smetterà di piovere nel bosco cadranno gocce per 5 minuti.....la natura ha un'ottima memoria..."

    http://www.kumbe.it

  4. #14
    ci sono e ci saranno è cambiato proprio il protocollo di comunicazione...quindi se metti mysql 4.1.x devi usare l'estensione mysqli...puoi anche mettere la mysql ma ti darà problemi di autenticazione
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  5. #15
    ma in sostanza il cambio di sintassi riguarda le varie funzioni

    *_connect
    *_select_db
    *_query

    dove * può essere mysql o mysqli ?

    perchè se è cosi io mi farei un programmino che cerca tutte le stringhe mysql* e le converte in mysqli*

    sempre che la variazione sia solo in questo....
    "durante i primi 5 miuti di pioggia nel bosco c'è ancora asciutto, poi quando smetterà di piovere nel bosco cadranno gocce per 5 minuti.....la natura ha un'ottima memoria..."

    http://www.kumbe.it

  6. #16
    diciamo quasi di si

    facendo il replace funziona, ma ci sono un sacco di funzioni nuove, quindi ti conviene anche dare un occhio per vedere se c'è qualche funzione che ti risparmia un po di lavoro
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  7. #17
    Vorrei un chiarimento su questa compatibilita'.

    mysql - mysqli non sono prestazioni di mysql 4.1.x, ma di php4 - 5.
    Quindi se hai php5 puoi usare "indifferentemente" mysql_* o mysqli_* se invece utilizzi php 4.x ovviamente solo mysql_*.

    Mysql 4.1 funziona benissimo con tutte le queries precedenti della versione 4.0, e con php 4.*

    Il trattamento della password e' un falso problema. Basta usare la funzione old_password() invece di password() e l'hash sara' rispettivamente di 16 o 40 digit.

    http://dev.mysql.com/doc/mysql/en/Old_client.html

    E' un mese che provo degli script della 4.0 sulla 4.1.7 e 4.1.8 e ne avessi trovato uno che non andava.

    Altrimenti viene la convinzione che mysql 4.1 "pretenda" php5. Diciamo che e' il contrario: PHP5 "pretende" mysql 4.1 o sup. per poter utilizzare mysqli_.

    Importante e' invece essere coscienti che se si sviluppa su mysql 4.1 (sia con php4 o con php5) il database non sara' compatibile con mysql 4.0, quindi il backup da mysql4.1 non funzionera' su mysql4.0, cosi' come il copia incolla dei file di database (pessima abitudine).

    Saranno pure incompatibili molte queries se pensate per la versione 4.1. Ma mai, ripeto mai, e' successo sinora la mancanza di compatibilita' (ad eccezione della password in mysql.user pocanzi detta) da queries o backup prodotti da 4.0 e portati sulla 4.1.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  8. #18
    ah....grazie!

    ora si spiega come mai su linux mi funzionava!

    ma io per criptare le password ho sempre usato
    Codice PHP:
    md5() 
    non va bene?
    "durante i primi 5 miuti di pioggia nel bosco c'è ancora asciutto, poi quando smetterà di piovere nel bosco cadranno gocce per 5 minuti.....la natura ha un'ottima memoria..."

    http://www.kumbe.it

  9. #19
    c'e password e password....

    Quelle tue le metti come ti pare .. anche in aramaico antico come si suol dire.

    La password di sistema, quella in mysql.user per intenderci, in mysql 4.1.7 e sup. e' prevista hashata in 40 digit. Chi fa l'hash (lato mysql) e' la funzione password() che e' stata modificata da 16 digit a 40 (cazzata non cambiare il nome).

    Cosi' pure fanno i nuovi CLIENT, mentre i vecchi CLIENT mysql (nel nostro contesto il client mysql di php 4 e prec.) continuano ad usare la loro funzione client password() che hasha a 16 digit.

    Che succede ora...

    Quando installi mysql 4.1.* il sistema di installazione od il tool wizard (che sono nuovi client) e ti chiedono la password, questa viene memorizzata in 40 digit nel campo password di mysql.user, senonche', quando cercherai di accedere come utente mysql, da un client tipo phpmyadmin su php 4 (vecchio client) il tentativo di accesso fornira' una password a 16 digit.

    Va da se che pur essendo la password digitata identica... col fischio che ti fa entrare.... uno ha 40 digit, l'altro 16.

    Ora, per eliminare questo problema e' sufficiente aggiornare il campo (da shell) modificando la password e memorizzarla a 16 digit con la funzione old_password(). Es.:
    codice:
    mysql> SET PASSWORD FOR
        -> 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
    oppure... aggiornando il campo, sempre da linea di comando poiche si suppone che php non riesce ad entrare:
    codice:
    mysql> UPDATE mysql.user SET Password = OLD_PASSWORD('newpwd')
        -> WHERE Host = 'some_host' AND User = 'some_user';
    mysql> FLUSH PRIVILEGES;
    Questo lo devi fare da tutti i CLIENT (3.qualcosa) che si interfacciano al server mysql compreso i driver ODBC, e non solo da php. Se il CLIENT mysql e' di tipo nuovo (non saprei al volo quale versione) potra gestire la password hashata a 40 bit.

    Ovviamente il CLIENT mysql su php5 e' di tipo nuovo e hasha a 40 digit.

    Quindi quando crei un utente basta usare la formuletta magica con old_password.

    Tutto questo non c'entra con mysqli_*, che sfrutta oggetti nativi di php5 per la gestione del CLIENT. Il SERVER se ne impippa di mysql_* o mysqli_ di php. Riceve dati SQL e quelli gestisce.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  10. #20
    Originariamente inviato da piero.mac
    Vorrei un chiarimento su questa compatibilita'.

    mysql - mysqli non sono prestazioni di mysql 4.1.x, ma di php4 - 5.
    Quindi se hai php5 puoi usare "indifferentemente" mysql_* o mysqli_* se invece utilizzi php 4.x ovviamente solo mysql_*.
    hanno modificato il protocollo per migliorarlo, quindi è ragionevole pensare che ci sia stato pure un incremento sul fronte prestazionale

    [QUOTE
    Mysql 4.1 funziona benissimo con tutte le queries precedenti della versione 4.0, e con php 4.*

    Il trattamento della password e' un falso problema. Basta usare la funzione old_password() invece di password() e l'hash sara' rispettivamente di 16 o 40 digit.

    http://dev.mysql.com/doc/mysql/en/Old_client.html

    E' un mese che provo degli script della 4.0 sulla 4.1.7 e 4.1.8 e ne avessi trovato uno che non andava.
    [/QUOTE]
    beh, si, è vero, ma hanno cambiato il sistema di gestione utenti per avere più sicurezza usando old password mysql usa anche il protocollo vecchio.

    Altrimenti viene la convinzione che mysql 4.1 "pretenda" php5. Diciamo che e' il contrario: PHP5 "pretende" mysql 4.1 o sup. per poter utilizzare mysqli_.

    Importante e' invece essere coscienti che se si sviluppa su mysql 4.1 (sia con php4 o con php5) il database non sara' compatibile con mysql 4.0, quindi il backup da mysql4.1 non funzionera' su mysql4.0, cosi' come il copia incolla dei file di database (pessima abitudine).
    il copia incolla di database certamente no, ma il dump sql ovviamente si, se vuoi fare un backup o una installazione di db da una 4.1 a una 4.0, apparte le tabelle di mysql (che quelle sono specifiche è poco si ci può fare) tutto il resto si può portare

    Saranno pure incompatibili molte queries se pensate per la versione 4.1. Ma mai, ripeto mai, e' successo sinora la mancanza di compatibilita' (ad eccezione della password in mysql.user pocanzi detta) da queries o backup prodotti da 4.0 e portati sulla 4.1.
    si infatti, il problema è che dovevano dare una sgrezzata (togliere il grezzo) ad un bel po di roba, perché la retro-compatibilità ti costringe a portarti dietro tutti gli acchiacchi delle architetture precedenti, che per quanto flessibili sono, sono sicuramente peggiori delle nuove (evoluzione)

    quindi secondo me non è importante solo passare a lavorare con mysql 4.1.x ma anche usare tutte le nuove funzioni che ci sono disponibili e passare ad usare le innodb che sono più velcoe e più prestanti (e soprattutto supportano le transazioni) rispetto alle myisam
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.