Query builder w bibliotece do obsługi bazy danych |
Query builder w bibliotece do obsługi bazy danych |
3.08.2017, 17:55:24
Post
#1
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
BoltDB
Pod powyższym linkiem znajduje się kod inicjacyjny dla biblioteki do obsługi bazy danych, którą tworzę. Po co? Żeby poćwiczyć niektóre rzeczy. Na razie działa tylko budowa prostego SELECTa poprzez klasy Select i SelectAbstract z odpowiednich namespaców. Chciałbym, żeby ktoś rzucił na to okiem (głównie namespace Cytat BoltDb\Engine\Mysql\Query i Cytat BoltDb\Engine\Query ). Od siebie mogę dodać, że prawdopodobnie kiepsko wymyśliłem zależności między interfejsami, traitami i klasami abstrakcyjnymi. Jak Wy byście to widzieli?//edit: Dodałem prosty tekst Readme Naprawdę nikt nie ma nic do dodania? Czy może mój kod jest tak sh*towy, że nikt nie chce go przeglądać? Ten post edytował czychacz 3.08.2017, 15:32:53 |
|
|
3.08.2017, 18:42:44
Post
#2
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
Hehe... Dobrze że dałeś tego readma...
Powiem Ci że jakieś to przekombinowane strasznie Za chusteczki nie wiedziałbym jak tego używać. Mało intuicyjne. Zerknij nawet w Laravela jak to mają ogarnięte: https://laravel.com/docs/5.4/queries#selects |
|
|
3.08.2017, 19:05:44
Post
#3
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
Widzę tam singletony dla tabel. Zastanawiałem się właśnie nad takim rozwiązaniem, dodając jakąś konfigurację albo automatyczne wykrywanie struktury (kierowałbym się ku konfiguracji, bo automatyka obciążałaby pewnie mocno skrypt). Ale póki co na razie chcę ogarnąć Query Buildera dla co najmniej podstawowych zapytań. Joiny z tego, co widzę, przyjmują mniejszą ilość parametrów, niż u mnie - tu wystarczy nazwa tabeli i warunek, a - jak się domyślam - lista pól uzupełniana jest z automatu lub przez dodanie listy. Ja tego chciałem uniknąć - wymusiłem listę pól (ale można użyć klasy \BoltDb\Query\Expression, by przemycić wildcarda '*'). Zrobiłem tak, ponieważ nie lubię systemów, gdzie jest zbyt dużo automatyki (stąd też podział na fromTable i fromQuery - także join*). Dodatkowo, listy pól przypisane są głównie do tabel lub podzapytań z nimi powiązanych (ale można użyć pól, które nie są z niczym powiązane, po użyciu Select::selectFields()).
Całe skomplikowanie dotyczy chyba właśnie podziału na klasy abstrakcyjne i interfejsy dla obiektów dotyczących pobrania danych - FromTable, FromQuery, JoinTable, JoinQuery - i przyszłych... |
|
|
3.08.2017, 19:51:57
Post
#4
|
|
Grupa: Zarejestrowani Postów: 1 240 Pomógł: 278 Dołączył: 11.03.2008 Ostrzeżenie: (0%) |
-------------------- |
|
|
3.08.2017, 20:24:17
Post
#5
|
|
Grupa: Zarejestrowani Postów: 6 366 Pomógł: 1115 Dołączył: 30.08.2006 Ostrzeżenie: (0%) |
Czym to się ma różnic od zend db bo nawet nazwy niektórych klas są identyczne
-------------------- |
|
|
3.08.2017, 20:26:16
Post
#6
|
|
Grupa: Zarejestrowani Postów: 673 Pomógł: 106 Dołączył: 31.12.2008 Ostrzeżenie: (0%) |
Zdecydowanie popracuj najpierw nad interfejsem, a dopiero potem bierz się za implementację. Dla Ciebie pewnie jest to intuicyjne, ale ja jestem przerażony tym co widzę, a to dopiero zwykły select
-------------------- |
|
|
4.08.2017, 09:11:49
Post
#7
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
|
|
|
4.08.2017, 16:00:23
Post
#8
|
|
Grupa: Moderatorzy Postów: 36 468 Pomógł: 6300 Dołączył: 27.12.2004 |
Jak juz zauwazyl markuz to twoje testy so cudne Przekazujesz true i sprawdzasz czy to true. Ciezko o sytuacjie, gdy to nie przejdzie testu
Co do klasy: a po co jest to cale Connection? Z przykladu w readme wynika ze do niczego, bo Najpierw dla connection ustawiam obiekt PDO, ktory sam tworze $pdo = new PDO('mysql:dbname=my_database;host=127.0.0.1;port=3306', 'username', 'password'); $connection->connect($pdo); a potem by wykonac query to musze to $pdo, ktore sam ustawilem, pobrac i dopiero moge wykonac query $result = $connection->getConnection()->query($select->toString()); Czemu poprostu nie moge zrobic $result = $pdo->query($select->toString()); i ominac to cale $connection? -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
4.08.2017, 17:04:57
Post
#9
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
Na chwilę obecną wrzucenie $select->toString() prosto do PDO nie będzie problemem. W sumie jeśli będę kontynuował rozwój tego skryptu to wątpię, żeby w ogóle nim było. Ale obszywanie w klasę Connection miało na celu łatwiejsze zarządzanie później dodanymi klasami (których oczywiście jeszcze nie ma). Na razie mamy tylko BoltDb\Engine\MySql, więc nie ma problemu, ale co, gdy dojdzie np. PostgreSQL? Connection i jego klasy podrzędne miałyby wtedy określić, z jakich zapytań mogę skorzystać, jakich konstrukcji użyć, itp.
Na razie jednak zastanawiam się nad sensem rozwijania tego skryptu - parę osób wspomniało, że jest zbyt skomplikowany. |
|
|
4.08.2017, 20:50:39
Post
#10
|
|
Grupa: Zarejestrowani Postów: 17 Pomógł: 2 Dołączył: 26.10.2013 Ostrzeżenie: (0%) |
Cześć,
Z góry powiem, że nie patrzyłem w kod i moje rady są na podstawie README.md. 1. Chłopaki mają racje popracuj nad api. Może nawet zacznij od niego.
Staraj się, żeby metoda nie posiadała więcej niż 2 parametry max 3.
Zrób fluent Bolt:f($pdo) ->select(Fields:f()) ->from(...) ->joinLeft("")->on("") ->get(); To tylko przykład , ale "you get idea"
Jako uatrakcyjnienie swojej biblioteki mógłbyś zwracać reactive object albo monadę/optional'a.
|
|
|
4.08.2017, 21:29:20
Post
#11
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
Metody dot. FROM i JOIN mają obowiązkowo 2 parametry - reszta to opcja.
Fluent wykluczony ze względu na to, że metody dodające bloki FROM i JOIN mają w przyszłości zwracać konfigurowalne bloki. |
|
|
4.08.2017, 22:39:55
Post
#12
|
|
Grupa: Moderatorzy Postów: 36 468 Pomógł: 6300 Dołączył: 27.12.2004 |
Cytat Metody dot. FROM i JOIN mają obowiązkowo 2 parametry - reszta to opcja. Acha, czyli jak metoda ma 2 parametry obowiazkowe, a 98 parametrow nieobowiazkowych to wg. ciebie ok?
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
5.08.2017, 08:32:58
Post
#13
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
A jak inaczej to rozwiązać? Publiczne settery na zwracanych obiektach? Według mnie to jeszcze gorsze niż 6-7 parametrów do fabryki.
|
|
|
5.08.2017, 09:56:06
Post
#14
|
|
Grupa: Zarejestrowani Postów: 17 Pomógł: 2 Dołączył: 26.10.2013 Ostrzeżenie: (0%) |
A jak inaczej to rozwiązać? Publiczne settery na zwracanych obiektach? Według mnie to jeszcze gorsze niż 6-7 parametrów do fabryki. Według mnie masz parę opcji: 1. Builder
2.
Generalnie skłaniam się do builderów i fluentApi bo dużo lepiej się je czyta niż settery. Jak masz więcej 5 - 7 parametrów to lepiej utworzyć 1 albo dwie klasy które przyjmują te parametry zgodnie z ich nazwą. W moim przypadku "Table" - posiada rzeczy dotyczące tabeli (nazwa, schema, klucz główny itd) , parametry dotyczące relacji uzupełniam w metodzie joinTable. Ten post edytował primosz67 5.08.2017, 09:56:42 |
|
|
5.08.2017, 10:14:33
Post
#15
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin Ostrzeżenie: (0%) |
Najlepiej byłoby się skłonić ku opcji pierwszej, ale nadal trzeba dodać parametry takie, jak lista pól. W moim założeniu powinno to być pogrupowane, dlatego u mnie jest to parametr metody fromTable/joinTable. W sumie mógłbym operować na obiektach klas zwracanych przez te metody...
|
|
|
Wersja Lo-Fi | Aktualny czas: 16.05.2024 - 18:16 |