69 odpovědí na toto téma

[MaFa]

Ona uz nejaka ta diskuse ohledne poradi podle logu problehla, ja s tim celkem nemam problem. Nicmene nejsem zadny programator, natoz databazovy, takze nejsem schopen napsat SQL dotaz, ktery by si s tim poradil. Jedna se totiz o trideni podle jine tabulky a to jenom v pripade, ze cas neni nastaven. Pokud nekdo vi jak na to, tak at sem nebo na SZ hodi ten select.

[lukabike.com]

Arne1 napsal/a:
Ne já nedám bez deníčku ani ránu (kešku)

Presne tak, jsem na tom uplne stejne. Notes mame taky, ale dost casto vezmu jen kus papiru do kapsy a je to. Najdu kes, zapisu do logbooku a pak na papir hodim cas a jmeno kese. Doma pak prepisu do GG a mam svaty klid Ta 4 cisla a dvojtecka me vazne nezbije

[pozorjed]

S474N napsal/a:
pozorjed: tak to si nepochopil, protoze Arne1 to samozrejme myslel jakozto rozpoznavani FTF u majitele Geogetu, tzn. toho, kdo je v nastaveni Geogetu.

ale pochopil, jen jsem chtěl předejít nesmyslným diskusím, bohužel se nedaří

[mpistora]

MaFa napsal/a:
Ona uz nejaka ta diskuse ohledne poradi podle logu problehla, ja s tim celkem nemam problem. Nicmene nejsem zadny programator, natoz databazovy, takze nejsem schopen napsat SQL dotaz, ktery by si s tim poradil. Jedna se totiz o trideni podle jine tabulky a to jenom v pripade, ze cas neni nastaven. Pokud nekdo vi jak na to, tak at sem nebo na SZ hodi ten select.

Díky za vstřícnost.
Zatím mi tu všichni radí, že si mám psát časy, ale nikdo už neříká jak a podle čeho je mám dopsat za 3 roky zpětně.
Přitom vše potřebné v datech je.

Zkusil jsem takový SELECT sestavit:

SELECT *
FROM geocache cache LEFT OUTER JOIN geolog log
ON log.id = cache.id AND log.type IN ("Found it", "Webcam photo taken", "Attended") AND log.finder = :owner
WHERE cache.dtfound > 0
ORDER BY cache.dtfound, cache.dtfoundtime, log.gs_logid

[MaFa]

Hlavně jestli takový select funguje ve všech případech, tj. i v případě, že log z nějakého důvodu chybí, třeba když se čas nastaví ručně. Jinak já občas časy doplňuju podle trasy zaznamenané v navigaci.

[mpistora]

Snažil jsem se, aby fungoval:
- Musí existovat cache s nasatveným datem nálezu
- Nálezový log nemusí být žádný, pak se v jeho sloupcích vrací null
- Většinou je jeden
- Může jich být i více, pak se cache opakuje a mění se část s logem.
A hlavně je to řazeno oním kýženým způsobem.


Přitom jsem si všiml, že v databázi GeoGetu u řady logů čas nálezu mám. A to proto, že ho GeoGet získal z času editace logu, např.:

[This entry was edited by PiTeam on Monday, May 12, 2008 at 12:05:37 PM.]

To by stálo za opravu (brát čas jen z prvních 20 znaků, nebo vyloučit čas v [ ]).

[pozorjed]

mpistora napsal/a: Zkusil jsem takový SELECT sestavit:

SELECT * 
FROM geocache cache LEFT OUTER JOIN geolog log 
ON log.id = cache.id AND log.type IN ("Found it", "Webcam photo taken", "Attended") AND log.finder = [i]:owner[/i]
WHERE cache.dtfound > 0 
ORDER BY cache.dtfound, cache.dtfoundtime, log.gs_logid

jo, to bude ono, já jsem dal blbě podmínku na druh logu až za where a tam to nemohlo zafungovat při neexistenci logu. Otestováno, nenašel jsem kombinaci, kdy by se nevrátil správný počet keší.
Při té příležitosti jsem si aspoň vyčistil 2 chybné záznamy (měl jsem 2 logy záznamy k jedné keši, vzniklo následně: log na stránkách GC.com, import do GG, pak jsem si vzpomněl, že jsem nedal in: TB, oprava logu už nebyla možná, smazal jsem log, vytvořil nový log včetně pohybu TB, tím pádem má nové LogID, import do GG a měl jsem hned 2 gs_logid ).

Zpomalení nepatrné, spíše má vliv velikost DB (mám pře 230MB) a rychlost čtení disku.

select G1.name, G1.guid, G1.id, G1.x, G1.y, G1.author, G1.cachetype, G1.cachesize, G1.cachestatus, G1.difficulty, G1.terrain, G1.dtfound, G1.dtfoundtime, G1.country, G1.state, G1.dthidden, G1.gs_ownerid, G2.gs_logid  from geocache G1
LEFT OUTER JOIN geolog G2 on G2.id = G1.id and G2.type in ("Attended", "Found it", "Webcam Photo Taken" ) and G2.finder = "CACHER" 
where G1.dtfound>0 
order by G1.dtfound, G1.dtfoundtime, G2.gs_logid

Tož někdy v další verzi GGStatu se můžeme těšit, dík.

To mpistora: k těm časům z logu, bylo by lepší čas doplnit jednorázově přímo do času nálezu, než ho při každém generování statistik parsovat z logu.

[MaFa]

Jasen, pokusim se to implementovat - pridam vase jmena, kdyby to nahodou nefungovalo

[pozorjed]

MaFa napsal/a:
Jasen, pokusim se to implementovat - pridam vase jmena, kdyby to nahodou nefungovalo

mohu zajistit 3 testery (každý se svou DB) pro ověření změny, než bude final verze.

[MaFa]

OK, tak ja to zkusim naimplementovat a poslu ti nekdy v nedeli nebo v pondeli balicek na vyzkouseni, driv se k tomu nedostanu.

[pozorjed]

MaFa napsal/a:
OK, tak ja to zkusim naimplementovat a poslu ti nekdy v nedeli nebo v pondeli balicek na vyzkouseni, driv se k tomu nedostanu.

V pohodě, když to nebylo doteď, tak týden nehraje roli. GC má být o hledání krabiček a zážitcích při tom, nikoliv o statistikách .

[MaFa]

Překvapivě jsem se k počítači dostal již dnes, takže bys to měl mít v poště - pokud přijme >3MB mail. Zdá se že to funguje, jenom je třeba mít logy v pořádku. Ale zase budou potěšeni ti, kteří mají jednu keš odlovenou vícekrát. Pokud mají 2 logy, keš se započte dvakrát, i když v obou případech se stejným datumem a časem!!! Takže žádná výhra. @Halumo nešlo by přidat nějakou funkci na mazání logů?

[mikrom]

MaFa: coz mi tak pripomina ze verze 27 vypada ze funguje, narozdil od 28 s implementovanym mazanim par-

[MaFa]

MaFa: coz mi tak pripomina ze verze 27 vypada ze funguje, narozdil od 28 s implementovanym mazanim par-

OK, tak ja to zase prelozim bez toho mazani

[mpistora]

pozorjed napsal/a:Při té příležitosti jsem si aspoň vyčistil 2 chybné záznamy (měl jsem 2 logy záznamy k jedné keši, vzniklo následně: log na stránkách GC.com, import do GG, pak jsem si vzpomněl, že jsem nedal in: TB, oprava logu už nebyla možná, smazal jsem log, vytvořil nový log včetně pohybu TB, tím pádem má nové LogID, import do GG a měl jsem hned 2 gs_logid ).

MaFa napsal/a:
@Halumo nešlo by přidat nějakou funkci na mazání logů?

Také jsem si všiml, že mám v databázi logy, které jsem už na gc.com smazal.
Synchronizace výmazů není jednoduchá (to že log není v importu, nemusí znamenat, že neexistuje).
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat. A to jen ze dnů před PQ.

Nyní jde log uživatelsky smazat asi jen tak, že se smaže celá keš a naimportuje znovu.

[mpistora]

MaFa napsal/a:
Ale zase budou potěšeni ti, kteří mají jednu keš odlovenou vícekrát. Pokud mají 2 logy, keš se započte dvakrát, i když v obou případech se stejným datumem a časem!!! Takže žádná výhra.

V takovém speciálním případě by asi bylo lepší brát datum nálezu z logů (a čas z cache použít k logu se stejným datem).

[HaLuMa]

mpistora napsal/a:
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat. A to jen ze dnů před PQ.

Spatna myslenka. Podle ceho ma GG z GPX poznat, ze bylo vytvorene zrovna tim spravnym tlacitkem na webu? Podle nvu v datech? To neni stale, muz se menit/ Taky nevis, jestli se data nejak mezitim necim nezmenila, treba jestli nebyla profiltrovana. A taky nevis, jestli jde o original, nebo jestli nejde o nejakou napodobeninu. A v neposledni rade, co kdyz nekdo udela PQ, ktere bude podobne?

v kazdem pripade je to vzdy velke riziko ztraty dat.

[pozorjed]

mpistora napsal/a:
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat.

Nesouhlas.
Zaloguji, stáhnu log do GG. Owner mi smaže log (teď neřešme z jakého důvodu), ale já mám stále uložené, co jsem tam napsal. A to chci mít stále uchované.
Pokud mazání logů, tak nějaké podmíněné.

[mpistora]

Vycházel jsem z vlastní zkušenosti: Když jsem odhalil, že mám na jedné keši dva nálezové logy (a tím , tak jsem jeden smazal na gc.com a celý proces (export, import, generování statistik) provedl znova. Zcela přirozeně (leč marně) jsem očekával, že se tím statistiky opraví. Že jde o pravé My Finds Pocket Query by se dalo kromě identifikací v záhlaví poznat takto: - u každé obsažené keše je alespoň jeden můj nálezový log - všechny obsažené logy jsou mé. Pak by se dalo celkem spolehlivě určit, že moje logy v databázi navíc, na gc.com nejsou. Jediný zádrhel je s časem - nelze to uplatnit na logy po vzniku PQ. Smazání by pak asi bylo rozumné nechat potvrdit uživatelem. Možná by bylo dobré mít v databázi i smazené logy. Ale používat je pro generování statistik nálezů je (po)chybné. Když už, tak by měly být odlišené.

[pozorjed]

mpistora napsal/a:
Možná by bylo dobré mít v databázi i smazené logy. Ale používat je pro generování statistik nálezů je (po)chybné. Když už, tak by měly být odlišené.

Však zatím logy nebyly potřeba pro účely statistik, například mě vyhovoval dosavadní zápis logu ve tvaru #poradi HH:MM (time) - logy s časem a byl klid. Jak chceš odlišit smazané logy? To by jsi musel neustále prověřovat, zda idlog v DB Geogetu stále existuje na stránkách GC.comm