Nieprawidłowa paginacja listy profili przy wyszukiwaniu

[Gość]

GG 12.4.111.12201
Reprodukcja:
1. Zacząć wyszukiwanie ludzi z katalogu, np. mężczyźni, lat 23-25, bez wpisywania miasta
2. Przewinąć wyniki trochę w dół
3. Poczekać 3 minuty
4. Znowu przewinąć w dół.

Efekt: Wyniki powtarzają się na liście.
Oczekiwanie: Wyniki nie powtarzają się.

Przyczyna: select do bazy danych z sortowaniem po niestabilnym kluczu z paginacją bez cache'owania wyników.
Rozwiązania:
1. Sortować wyniki po stabilnym kluczu, np.:
a) Numerze gg
b) Czasie ostatniego bycia online w chwili zapytania, tj. zcache'ować wynik zapytania na serwerze i kolejne selecty do dalszych stron pobierają
2. Przesyłać od razu całą listę kluczy do klienta, ileż to może ważyć, 10 kilobajtów? Pseudonimy, awatary i tak pobiera w osobnym zapytaniu do serwera. Nie używać OFFSET w zapytaniach SQL.
3. Dodać w profilu pole na wybór "konto do RP", "wymagam daniny", "nie pokazuję zdjęć" i umożliwić odfiltrowanie niepasujących w wyszukiwaniu - w ten sposób nawet przy bałaganie w wynikach wyszukiwania łapiej będzie się odnaleźć użytkownikowi.

Ciekawostka: problem nie pojawia się przy wybraniu miasta. Użyty stabilniejszy klucz?

[Meduza]

GG 12.4.111.12201
Reprodukcja:
1. Zacząć wyszukiwanie ludzi z katalogu, np. mężczyźni, lat 23-25, bez wpisywania miasta
2. Przewinąć wyniki trochę w dół
3. Poczekać 3 minuty
4. Znowu przewinąć w dół.

Efekt: Wyniki powtarzają się na liście.
Oczekiwanie: Wyniki nie powtarzają się.

Przyczyna: select do bazy danych z sortowaniem po niestabilnym kluczu z paginacją bez cache'owania wyników.

Nie cach-ujemy wyników z kolejnych stron, których Użytkownik jeszcze nie odwiedził.

1. Sortować wyniki po stabilnym kluczu, np.:
a) Numerze gg
b) Czasie ostatniego bycia online w chwili zapytania, tj. zcache'ować wynik zapytania na serwerze i kolejne selecty do dalszych stron pobierają

Sortujemy po dopasowaniu do kryterium wyszukiwań oraz tym czy Użytkownik posiada GG Premium i profil zweryfikowany, a następnie po statusie i czasie ostatniego zalogowania.
Używamy statusu i czasu zalogowania dlatego w zależności od momentu wyszukiwania dostaniemy inne wyniki.

2. Przesyłać od razu całą listę kluczy do klienta, ileż to może ważyć, 10 kilobajtów? Pseudonimy, awatary i tak pobiera w osobnym zapytaniu do serwera. Nie używać OFFSET w zapytaniach SQL.

Nie wyciągamy od razu wszystkich wyników dla danego zapytania, m.in. ze względu na to, że może być ich bardzo dużo - nawet dziesiątki tysięcy kont
przy braku zawężenia kryterium wyszukiwania - co by było bardzo mocno obciążające dla naszych systemów
(zarówno pod względem zużycia dysku i procesora jak i pamięci), a zysk dla Użytkownika byłby minimalny.

3. Dodać w profilu pole na wybór "konto do RP", "wymagam daniny", "nie pokazuję zdjęć" i umożliwić odfiltrowanie niepasujących w wyszukiwaniu - w ten sposób nawet przy bałaganie w wynikach wyszukiwania łapiej będzie się odnaleźć użytkownikowi.

Nie ma możliwości podania negatywnych kryteriów do wyszukiwania i nie planujemy tego dodawać.

Ciekawostka: problem nie pojawia się przy wybraniu miasta. Użyty stabilniejszy klucz?

Zwracanych jest wtedy mniej wyników, i jest mniej kont, które przez te "3 minuty" będą zmieniać status/logować się.
W związku z tym wyniki robione po pewnym czasie będą się mniej różnić. Mechanizm sortowania i cachowania jest ten sam.

[Gość]

Ok, nie naprawią. Mój workaround: od razu po wyszukiwaniu przewijać w dół do samego "końca", buforuje się w ten sposób kilkaset wyników i potem już można przewijać między nimi bez powtórzeń. Traci cały sens wydajnościowy paginacji, ale to już ich problem.

[Gość]

Dobra, już rozwiązałem ten problem. Wygrzebałem z archiwum swój stary programik używający libgadu i, nie było tu zaskoczenia, działał bez żadnej modyfikacji w wersji z 2017 roku. Programik sam sprawdza czy nie ma powtórzeń i ewentualnie eliminuje je. Taniej i łatwiej było użyć "pirackiego" softu niż doprosić się naprawienia błędu w supporcie, za który przecież płacę. Usuwam też konto na tym forum, nie ma sensu dalsze produkowanie się. Nasza klasa jak upadała była w dużo lepszym stanie niż ten projekt.