Nakładka mysql_* na PDO |
Nakładka mysql_* na PDO |
25.11.2013, 16:26:49
Post
#1
|
|
Grupa: Zarejestrowani Postów: 29 Pomógł: 0 Dołączył: 11.05.2013 Ostrzeżenie: (0%) |
Pogrążony nudą, napisałem dziś dość ciekawy skrypt, który za zadanie ma wyglądać w 100% jak składnia zapytań mysql_*, jednak jego mechanika opiera się w całości o PDO.
Jak to działa? Skrypt podmienia dużą ilość funkcji oferowanych przez mysql_*, na funkcje, które zostały przepisane samemu, a ich działanie to tak naprawdę biblioteka PHP Data Objects, do której możemy odnosić się "starymi" instrukcjami. Po co to komu? Zastosowań takiego rozwiązania może być wiele. Najbardziej cieakwe z nich okazują się wtedy, gdy nasz gotowy projekt korzysta z połączenia z bazą danych przy użyciu mysql_connect, jednak chcielibyśmy zacząć używać nowszej i lepszej techniki (mowa o PDO), ale nie mamy zamiaru przepisywać całego skryptu od nowa. W takim wypadku wystarczy dołączyć prezentowaną nakładkę, a problem zniknie. Jeśli mowa o problemach, wyobraźmy sobie, że nasz serwer w ogóle już nie oferuje wsparcia dla mysql_connect, a Twój skrypt to w całości ta metoda. Co robić? Korzystając z nakładki, żaden serwer nie wyrzuci informacji, o braku wsparcia lub przestarzałej funkcji. Jeśli nie masz zamiaru uczyć się PDO, czy mysqli, bo w php nie programujesz za często, ten skrypt może zaoszczędzić Ci dużo czasu. Zalety nakładki: + szybkość tworzenia aplikacji + skrypt opiera się o PDO, czyli dużo nowszym interfejsie komunikacji z bazą danych niż mysql_connect + wymaga zaledwie 3 linijek zmian + kompatybilność z Twoim kodem, dzięki przeportowanej dużej liczbie funkcji, a także zachowanym miejscem na dodatkowe parametry, nie musisz nic więcej edytować w swojej aplikacji + funkcja mysql_real_escape_string posiada filtrowanie oparte o filter_var + możliwość połączenia się z takimi systemami jak PostgreSQL, czy SQLite, bez żadnych dodatkwoych zmian! Wady nakładki: - brak jakiejkolwiek obsługi błędów, w przypadku gdy nasz kod nie działa, problemów musimy doszukiwać się całkowicie indywidualnie - jakiś procent spadku wydajności, spowodowany oczywiście nadpisywaniem funkcji Lista funkcji, które zostały zawarte w nakładce: - mysql_connect - mysql_select_db - mysql_set_charset - mysql_query - mysql_fetch_array - mysql_fetch_assoc - mysql_fetch_row - mysql_fetch_object - mysql_real_escape_string - mysql_num_rows - mysql_affected_rows - mysql_create_db - mysql_drop_db - mysql_errno - mysql_error (atrapa) - mysql_close Przejdźmy do rzeczy, kod nakładki prezentuje się tak:
A oto przykład jego użycia:
Jedyne o czym trzeba pamiętać, to tych 2 linijkach w każdym z plików zawierającym instrukcje mysql:
Oraz oczywiście dołączeniu samej nakładki Co Wy na to? Bzdet, czy raczej komuś może się przyda? Ten post edytował SlimShady 25.11.2013, 16:31:01 -------------------- wszystkie drogi prowadzą do manuala :3
|
|
|
25.11.2013, 17:35:43
Post
#2
|
|
Grupa: Zarejestrowani Postów: 3 034 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
powiem krótko poco, ale może zajdziesz kogoś kto się na to skusi, ale tak naprawdę coś takiego nie ma najmniejszego sensu.. Po to jest PDO, żeby go używać, ponadto masz przecież strukturalny mysqli gdzie jedyna zmianą w podstawowych zapytaniach jest dopisanie litery i, wiec chyba odpowiedź nasuwa się sama, chciałeś dobrze ale poto wycofali mysql_* z php, żeby ludzie skończyli tworzyć zapytania w oparciu o tę bibliotekę, bo jest przestarzała, podatna na wszelkiego rodzaju atak itd... A wepchniecie w stare metody PDO, nie wiele da, bo minusy tego rozwiązania dalej pozostaną, wiec już lepiej nauczyć się PDO czy tez mysqli
Ten post edytował com 25.11.2013, 17:36:16 |
|
|
15.02.2014, 11:35:34
Post
#3
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
Jako chwilowa proteza na bolące zęby jak znalazł.
Wiem z doświadczenia że jeżeli serwis jest całkiem pokaźny bo pisany przez xxx ludzi sprzed 10 lat to taki system w pewnym momencie przestaje działać. A bo serwer zrobim update PHP z 5.2 lub (o zgrozo) PHP4 na PHP 5.4 - 5.5 i du... serwis leży. Aczkolwiek trzeba ludzi zmuszać żeby rezygnowali ze starego na nowe, bo to się opłaca przyszłościowo. |
|
|
15.02.2014, 16:59:17
Post
#4
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Przecież to wprowadza jedynie wylęgarnia nowych błędów i luk bezpieczeństwa oraz jeszcze większe ograniczenie możliwości starego sterownika mysql_*(). Zmienne globalne, tylko jedno połączenie, błędne zachowanie (np. przy zapytaniu EXPLAIN SELECT, czy mysql_real_escape_string). A pożytku z PDO tutaj żadnego nie ma. Zaś sam sterownik mysql_*() mimo iż już wprost oznaczony jako przestarzały jeszcze przez długi czas raczej nie zniknie.
@Pyton_000: Nowe jak nowe, PDO ma 8.5 lat. Ten post edytował Crozin 15.02.2014, 17:03:54 |
|
|
15.02.2014, 20:27:48
Post
#5
|
|
Grupa: Zarejestrowani Postów: 3 034 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
Pyton_000 No zgadzam się i tym bardzie wtedy nie zalecane, a wskazane jest zebranie zespołu tych xxx ludzi żeby taki serwis przepisać na nowo, z kilku powodów, po pierwsze czy 10 lat temu ktoś się wgl przejmował SQL Injection i tym podobnym, albo czy dbano o to żeby chronić się przed XSS, nie wtedy mało kto o tym miał pojecie i takie serwisy są dziurawe jak ser szwajcarski ponadto już trochę nie z tej epoki, gdzie dobrze było jak dodawano addslashes i na tym się kończyło... wiec patrzenie na to w ten sposób jest błędem, tym bardziej, że "nowe" wcale nie jest trudne, jedyny problem, ze wszystkie kursy nadal tworzy się używając mysql_* i dlatego dalej jest wylew zapytań na tym silniku..
|
|
|
15.02.2014, 20:46:42
Post
#6
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
com Byłoby fajnie gdyby te xxx ludzi pracowało dalej ;D
Realia są takie że teraz średnim przedsiębiorcom trudno jest na rynku. Każdy patrzy jak by tu działało. U mnie w firmie w której pracuję obecnie szef nawet nie wie jak wygląda aplikacja od środka która sprzedaje A co ja tam będę się tłumaczył ;P Trzeba pisać ładnie, składnie i z rozmysłem, a takie lepienie i tak się odbije wieeelkim echem w aplikacjach long-term i to bardzo boleśnie. |
|
|
15.02.2014, 21:08:00
Post
#7
|
|
Grupa: Zarejestrowani Postów: 3 034 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
Pyton_000 Tak tylko ja wcale nie napisałem, że to ma być ten sam skład co 10 lat temu, bo jest duże prawdopodobieństwo, że ich wiedza na mysql_* się kończy.. chodziło mi generalnie o to, że technologia gna do przodu i łatanie starych dziur w ten sposób po prostu mija się z celem, bo po pierwsze samo to się nie zrobi, wiec użycie tej "nakładki" tak czy tak wymaga ingerencji jakiegoś zespołu który to zrobi, wiec to nie ma sensu bo oni przecież za darmo tego nie zrobią, a takie rozwiązanie będzie tylko doraźne, ponadto tak jak napisał Crozin z czym się w całości zgadzam "to wprowadzi jedynie wylęgarnie nowych błędów i luk bezpieczeństwa oraz jeszcze większe ograniczenie możliwości starego sterownika mysql_*()."
|
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 01:32 |