Importovaný WM http://www.waymarking.com/waymarks/WMANY8
naleznu v GG podle CTRL-F (i podle neúplného názvu - např. 2112 nebo vyseb
podle CTRL-G jen podle úplného ID - tj. WMANY8.
Hledání podle úplného ID je v GG nutnost nebo to nikdo v GG nepoužívá?
Nahrál jsem si do GG databázi CGP http://www.geocaching.cz/forum/viewthread.php?forum_id=36&thread_id=17735&sort=&rowstart=0. Pole ID a Název má trochu odlišná od běžných WM a GC* kódů kešek. Na tyhle body ale nefunguje ani CTRL-F ani CTRL-G (i při zadání plného ID nebo názvu) :(.
ToRo61: tipuji, ze to nikdo nepouzival/nepotreboval a proto tohle neni mozne. Ale asi by se mel vyjadrit Haluma.
Podle ID se hleda presna shoda. Nicmene vyzkousim i tu castecnou, jak se to bude jevit rychlostne, protoze v tu chvili se nepouziji indexy.
V tuto chvili je to v kategorii zahad. Oboje hledani ztroskota na stejne veci, nepodari se udelat databazovy dotaz na nahledane ID. (ackoliv v databazi zjevne je, kdyz jsem jej o prikaz pred tim z databaze precetl.)
Trasoval jsem to az na uroven Sqlite, a nenalezl problem, sqlite na ten dotaz skutecne nic nevrati. Pritom ze Sqlite konzole to chodi.
Vyrobil jsem si i specielni testovaci aplikaci, ktera si udela zkusebni tabulku o jednom sloupci, a i tam se mi nedari vyselectovat prislusny zaznam.
Pritom na mych starych GG databazich (i negeocachingovych) to chodi dobre. Takze to klidne muze byt nejaka nova chyba v Sqlite.
Pozdeji vecer budu pokracovat v patrani.
Hm, to docela "potěší", když je bordel v backendu, za který nemůžeš.
Částečná shoda by potěšila, ale tu rychlost růžově nevidím… Třeba překvapí. 
A co pridelat zaskrtavatko, ktere da uzivateli na vyber. Kdyz vybere ‘substring’, musi si byt vedom toho, ze to bude trvat dele. Pro kese to asi moc smysl nema, ale pro "nekesove" databaze, by to urcite bylo vyznamne plus.
Hledani bez indexu neni v tomto pripade problem. Podivejte se, jak dlouho se hleda podle nazvu. A to se hleda take bezindexu, a jeste ve dvoutabulkach. (geocache a waypointy). Pochopitelne to trva dele, ale porad je to dostatecne rychle.
Tak je pravda, ze tabulka s 50000 zaznamy je z databazoveho hlediska malickost.
Ohledne toho hledani… tak Sqlite za to nemuze. Nejdrive jsem odhalil chybu v mem testovacim kodu, ktery se pak zacal chovat spravne. No a pak uz byl krucek k tomu, abych odhalil onen schovany problem v GG.
Cely problem zpusobila mala pismena v ID bodu.
Tak jsem rád, že má šťouravost vede ke zvýšení kvality GG :).
Jinak to ‘fulltextové’ hledání v ID i názvu bodu asi není až tak vyjímečný požadavek. V GSAKu to funguje rovněž a dokonce tak, že lze paralelně kombinovat hledání v ID i názvu a ještě to funguje jako inkrementální search - průběžně se zadáním hledaných řetězců to aktualizuje množinu zobrazených bodů.