Za mne perfektní, živá mapa funguje hezky svižně.
V LOCUSU se podle me nic nezapina, nebo jo?
Máš recht, v Locusu je potřeba povolit periodické aktualizace: Nastavení > Různé > Různé: Propojit s doplňky
Jeste se chci zeptat, zda bylo implementovano to nove nastaveni pro logy? Musim lepe overit az doma, ale nejak se mi to nezda....
Máš recht, v Locusu je potřeba povolit periodické aktualizace: Nastavení > Různé > Různé: Propojit s doplňky
Hura, live mapa funguje! Koukal jsem na to, ale myslel jsem, ze souvisi s napr. s hodinkami - cili smer z Locus ven!
Diky.
Nezdá se ti to správně, teď jsem to zkusil a to řazení podle key v praxi nefunguje:
SELECT key, gs_logid, type, dt FROM geolog WHERE id = 'GCY81P' ORDER BY key DESC LIMIT 15key gs_logid type dt
31658 904622320 Found it 20200122
31657 904691213 Found it 20200122
31656 906025315 Found it 20200131
31655 906116332 Found it 20200131
31654 906127817 Found it 20200201
Takže asi řadit přes gs_logid nebo dt
Pokud bude někdo logovat zpětně, tak to gs_logid taky nebude odpovídat. Tak jedině to řadit dle dt.
Ono jde i o to, v jakém pořadí přijdou logy, které importujes do Geogetu. Key ti zachytí pořadí importu, ne vzniku logu. Gs_logid zase zachytí pořadí logovani na webu, a při zpětném logovani to také nesedi.
Já bych doporučil řadit podle dt, a druhotně podle logid.
Já bych doporučil řadit podle dt, a druhotně podle logid.
ano, pokud to má být deterministické (pokaždé stejné) tak je nutné řadit podle dvou sloupců. Příčina je ve špatném návrhu tabulek a sloupců a jejich obsahu. Ale není to nic s čím by si šikovná ruka zdejšího mozkovéhu trustu neporadila.
Dekuji ti, nacelniku, ze ses mne zastal. B)
Navrh je dan historii a pak take tim, co poskytuje a poskytoval GS. O zmene struktury se mluvi v nasich kruzich odhadem tak 6 let, ale asi neni odvaha ;)
Dal by prosím dohromady místní mozkový trust ten dotaz na logy řazené dle důležitosti nebo jak tomu budeme říkat. V základu bude posledních X logů dle dt a gs_logid. Pak bude možnost si zvolit posledních X logů dle důležitosti. Pokud možno, aby to byl jeden dotaz se vstupem id keše a limit. Pokud tam chcete přátele je to na vás, přidám tam textové nastavení přátel. Je to o diskusi.
Vím, že jsem dával nalano jeden select a tarmara jestli se nepletu taky, tak kdyžtak dejte (klidně tady) hlavy dohromady.
Jde o to, jaky to ma mit smysl. Nez zacnem vymyslet SQL, dejme napred pozadavek.
Posledni "dulezite logy" maji podle meho smysl jedine kdyz jde o presun souradnic, pripadne jeste enable/disable. Takze max 3 logy, ktere nebudou v poradi podle data.
Ja bych tedy videl poslednich X logu + 3 "dulezite", pokud neni nektery z nich v tech X. Tedy X logu podle dt+gs_logid, 3 dulezite, seradit podle dt+gs_logid a vyhodit duplicity (ty klidne testovat podle rowid).
EDIT: Aby bylo jasno, temi dulezitymi logy myslim vsechny logy, ktere patri autorovi kese.
Tak jak pise gord je to podle me pouzitelne a pro me naprosto idealni.
Jsem lehce upravil select na logy http://www.geocaching.cz/topic/32567-locus-map-doplněk-geoget4locus/?p=581074 Je tam změna řazení a výběru posledního podle dt a logid. U mne je to hledání a groupování dle těchto polí stejně rychlé jako dle key
Potřebuje to 3 parametry GCxxx, seznam přátel a max. počet logů.
Typ posledních důležitých logů je možné omezit ve WHERE v prvním subselectu. Ale myslím, že každý druh logu má svůj význam. Možná je nejvíc nezajímavé starší Write note, a DNF
Hlásím, že živá mapa funguje ve verzi 0.13 i na Androidu 6.
Jsem lehce upravil select na logy
u logu kamosu je treba upravit hodnotu xx sloupce asi na "2". A pri duplicitnich logach bude pri GROUP BY pocet vracenych logu snizen pod pozadovanou hodnotu poctu logu. a ten trojity UNION (bez ALL, tudiz resici v tu chvili nepotrebnou distict ulohu) v kombinaci s trojitym pristupem do jedne tabulky (vc. filtru) taky nebude optimalni. Pokusim se to co nejdriv prepsat s window funkcemi. Zadani je celkem jasne....
Ano. Tu 2 jsem tam původně měl. To vnější group odstraňuje vícenásobné záznamy na úkor celkového počtu záznamů. Celé to groupování a řazení se provádí nad množinou logů k 1 keši, tedy většinou na množinou velikou řádově jednotky - desítky záznamu. To je pro databázi vždy rychlejší než následně předání dat klientovi. Na mé veliké databázi trval dotaz cca 10 ms. To asi nemá smysl zrychlovat. Tento dotaz se tam volá při otevírání detailu keše, tam budou stonásobně větší časy např. při stahování a zobrazení obrázku do listingu.
Jsem docela zvědav, jaké rychlosti to bude mít vůči standardní metodě.
Teď jen doplním, že ano, ten dotaz se volá při otevírání detailu jedné keše, ale zároveň, pokud se importují keše kompletně (režm Import se všemi daty), tak se to volá u každé keše.
- jak řešit logy u keší kámošů? jejich logy by totiž při prioritizaci zabraly celý limit. Nebo u eventů, kde kámoši obvykle zaberou každý dva logy (WA a A)
- předchozího bodu se týká případné zjišťování ownera keše: obzvláště u eventů bývá vlastnictví sdíleno (geocache.author obsahuje složeninu z více nicků), podobně to bývá u adoptovaných keší viz
select * from geocache where author like '%tarmara%';
- jak vidno tak s kámošema je potíž :), resp, nebyli dostatečně zadefinování....
select * from (
select * from (
SELECT
geolog.*,
rank() over (partition by id, type order by dt desc, gs_logid desc) as rnk /*každému záznamu v rámci oddílu/partition (výsledek implicitního GROUP BY) je přiřazeno pořadí při daném řazení*/,
case
when /*dulezite logy*/ type IN ('Update Coordinates', 'Temporarily Disable Listing', 'Enable Listing', 'Needs Maintenance', 'Announcement') then 10
when /*sledovani kaceri*/ finder IN ('HADI Z Lyse', 'dejwy') then /*tohle nadela paseku u kesi pratel, a na druhou stranu nejde jednoduse zjistovat ci kes je - viz sdilene eventy, kdy je v geocache.author vic kaceru a musel by se pouzivat IN */ 5
when /*obycejne logy*/ type IN ('Didn''t find it', 'Found it', 'Attended', 'Webcam Photo Taken') then 0
else -1 end as ord
FROM geolog where id=/*'GCT0KG'*/'GC66BBR'
)
where ((rnk=1 and ord>5) or ord<=5 /*5 (nebo vybraná hranice z CASE) je použita jako hraniční hodnota pro ktterou se berou jen poslední logy daného typu*/)
order by ord desc, dt desc, gs_logid desc
Limit 20 /*celkový limit, mám radši, když je vrácen vždy stejný počet záznamů*/
)
order by dt desc, gs_logid desc;
- testoval jsem rychlost mého (s rank() fcí) a nalano dotazu. Subjektivně je to jedno, dle SQLite studia se doba běhu pohybuje na SSD v setinách vteřiny i u mojí keše, kde to musí přebrat >1400 logů. Chtělo by to zkusit v cyklu při generování gpx, kdy to poběží pro víc keší za sebou. Možná se tam projeví db režie. Ale jeden i druhý dotaz už je prvotně zoptimalizovaný celkem pěkně. Takže bych teď nechal na YaMD, jaký si vybere dotaz a pustil to mezi uživatele na testování. Další optimalizaci bych řešil za provozu.
- včera jsem testoval LM při navigaci v Locusu a i při dynamickém zoomu se keše načítají celkem svižně. Příští týden jedu do Rakous tak to otestuju jak při jízdě po dálnici, tak při motání se po horách. DB má přes 100k keší jen za CZ, s Rakouskemu se dostanu přes 200k kousků, takže bude vidět rychlost provádění dotazů.
- jak často je při LM dotazována databáze? Při každém pohybu v mapě? Nebo je to i vázáno časově? Aby se to při rychlém pohybu neptalo každou vteřinu a dotaz se nevyhodnocoval vteřiny dvě...
Autor je vzdy jen jeden jediny, na nej odkazuje ownerId. Z nej lze zjistit skutecneho vlastnika. Do toho textoveho pole si autor v odstate muze napsat co jej napadne.
OwnerId lze prevest na referenceCode a k nemu nacist nick autora. Ziskani referenceCode lze udelat offline ale referenceCode -> nick je mozny jen pouzitim API, i kdyz je dost pravdepodobne, ze owner uz v databazi se stejnym ownerId bude, ale jak ho poznat od tech falesnych me nenapada.
U eventu se, podle meho nema, smysl zabyvat s nejakym dotahovanim poslednich logu. Ty nemaji pro "nalezeni kese" zadny vyznam.