Wchodze w dzial Praca, otwieram 3 strone i jest pusta. Wszyskie strony >2 sa puste (a mam ich 16) :|
0
0
W działach z automatycznym usuwaniem ten błąd jest znany Bug #407, ale w działach normalnych?
Brak kluczy obcych [w wersji MySQL aktualnej gdy kod był pisany] daje takie efekty...
0
Hmm wyglada na to ze to jest we wszystkich dzialach, ot chociazby i w C/C++
0
Wygląda na to że moje pagination jest skopane, dziw bierze że wyszło dopiero po tak długim czasie ;-)
Zajrze niedługo.
0
A jednak to nie problem z pagination a z usuwaniem postów. W bazie jest pełno wątków których first_post_id wskazuje na nieistniejący post (usunięty)
0
Damn it. Czyli jednym slowem skopana jest funkcja automatycznie oprozniajaca dane kategorie? Usuwa posty, a tematy zostawia?
0
No to było wiadome od dawna, ale jakoś czasu nie było na szukanie buga ;)
0
no ja kiedys to sprawdzalem i bylo ok na lokalu. Wlasnie nie moglem dojsc do tego co sie dzieje...
0
Mamy już noooooooooooooowszą wersję MySQL - może warto dodać w końcu relacje i pozwolić bazie na:
- samoczyszczenie się [on delete cascade]
- informowanie o błędach [próba usunięcia powiązanego klucza i bum - mamy namiar na źródło błędu]
0
Hmmm. Mam nadzieję, że się mylę, ale... Czy mysql nie obsługuje kluczy obcych tylko na tabelach INNODB? Bo z kolei z tego co pamiętam to na tabelach InnoDB nie ma wyszukiwania pełnotekstowego...
0
Qyon: yep, to prawda.
0
Uh.. mea culpa
No to skoro nie można zwykłymi metodami namierzyć problemu, to... zmienić bazę na InnoDB na localu i tam potestować ;)
0
To ja ponarzekam na dział praca.
Panowie proszę o przemyślenie tego by dodać SFO (Standardowy Formularz Ogłoszenia), bo coraz więcej ogłoszeń wygląda bardzo nieprofesjonalnie. A tak może jak będzie można wyklikać ogłoszenie to ludzie postarają się wlać w nie trochę treści.
0
Koziołek: może to o czym mówisz, to długo zapowiadany "dział Praca" który ponoć ma się pojawić w nowym Coyocie ;)
0
Hihih, no wlasnie "dlugo". Chyba Duke Nukem Forever wyjdzie wczesniej :P
0
Adam Boduch napisał(a)
Chyba Duke Nukem Forever wyjdzie wczesniej :P
Buachachachachacha :D
Ale ryknąłem śmiechem :D
Wracając na chwilę do InnoDB i MyISAM. Proponuję rozwiązanie, jakie jest w MediaWiki - różny typ tabel dla różnych danych:
- standardowo - InnoDB
- tabele z treścią - MyISAM - co by szukarka mogła korzystać z indeksu full text
- tabele często zmieniające się i mogące ulec usunięciu (jak whoisonline) - Memory
A co do działu praca. Nowy Coyote miał obsługiwać system wtyczek. Wtedy możnaby się podpiąć i dla działów ID=xxx wykonywać wtyczkę, która mogłaby podmienić stronę tworzenia wątku. Niestety, premiera Duke'a się przeciąga ;)
0
@Marooned: Tak, tez nad tym myslalem. Generalnie w jakis projektach jak teraz robie to nieczesto uzywam tabel MyISAM.
To jest wlasnie cholerna wada MySQL, ze trzeba sie glowic nad roznymi engine tabel. No bo, tabela coyote_post musi obslugiwac FULLTEXT (tak samo coyote_topic), a tam bardzo by sie przydalo usuwania kaskadowe ;/
Aby zapewnic integralnosc danych w tych tabelach (gdy nie mamy mozliwosci zakladania kluczy obcych), chyba najlepiej wykorzystrac triggery.
0
Ostatecznie możnaby podzielić _posts na 2 tabele:
InnoDB: id, wszystko inne
MyISAM: id, text
ale to by dołożyło kolejnego joina do SQL.. heh
zawsze można też pomyśleć o przejściu na PosgreSQL ;-)
0
@Marooned, z tym postgresem to już gdzieś była rozmowa. Można jeszcze dołożyć jakiś indekser do wyszukiwarki.
0
Ale myślę, że najmniej wymagającym rozwiązaniem będzie to, co wspomniałem powyżej. Postawienie lokalnego kojota, wszystkie tabele na InnoDB + relacje, testowanie.. na podstawie błędów zwróconych z bazy z relacjami naprawa kodu tak, by działało to ok na MyISAM.
Ot, takie wykorzystanie relacji w formie debuggera. Może i nieładne, ale skuteczne.