320 odpovědí na toto téma

[vkvkvk]

Dle Halumy: Pak po kazde API operaci najdes v TEMP adresari v datovem adresari textove soubory s holymi daty, ktera pres API pritekla.

Musíš se mrknout do podadresáře.

[vkvkvk]

Např. já mám temp v C:\Users\vkvkvk\AppData\Roaming\GeoGet\temp

[Arne1]

HaLuMa: Chceš ode mne poslat ten TEMP nebo ti popis stačil ?

[mpik]

Jo, v tempu, tam soubory jsou. Ale protože nevím, jak tady přes fórum poslat soubory, poslal jsem soukromou zprávou alespoň jejich obsah.

[HaLuMa]

Arne1: No, te obecny popis mi k nicemu prakticky neni. Pokud ty kese v tech souborech nejsou, tak si je tam nevymyslim. ;-)

 

Kdyz zkusis na nektere te nezaktualizovane kesi dat prave tlacitko, a prave tuhle jednu kesku zaktualizovat, tak se to udela spravne?

[Arne1]

Podle toho popisu to můžeš snadno reprodukovat. Zkoušel jsem několik menších států - Srbsko, Bělorusko, Egypt. Vždycky se stáhlo o několik keší méně, přitom to nejsou vždy ty samé keše  a ani  počet chybějících není stejný. Dotáhnout libovolnou keš přes aktualizaci samozřejmě není problém.

[HaLuMa]

pockej, takze kdyz stahujes tentyz stat nekolikrat za sebou, tak pokazde chybi neco jineho?

[HaLuMa]

3) taková nehezká drobnůstka - viz příloha 

 

Drobnustka by mela byt opravena.

[HaLuMa]

poslední beta - Stáhnout kešky: nestahne se nic, i když se snažím jen o lite listingy. Type value is not valid.

 

Opraveno.

Pravdepodobne sis ve vyberu typu kesi vsechno odskrtnul (nebo mozn naopak zaskrtnul uplne vsechno), a ono se to takhle pomatlo.

 

Zkus schvalne zaskrtnout vsechno, treba vyjma HQ kese. A melo by ti to fungovat.

[Arne1]

pockej, takze kdyz stahujes tentyz stat nekolikrat za sebou, tak pokazde chybi neco jineho?

však jsem to několikrát psal ! Však si to zkus, například Srbska by mělo být 561 kousků. Může se stát, že podruhé to bude správně. A po chvíli zase bude něco chybět.

Tento příspěvek byl upraven od Arne1: 11 duben 2019 - 19:35

[HaLuMa]

Tak to byl velmi zajimavy problem!

 

Nutno si uvedomit, jak to vyhledavani probiha. Zadas vyhledavaci kriteria, a server podle techto kriterii vyhleda nejaky seznam kesek. Z tohoto seznamu ti ale vrati maximalne 50 z nich. Pokud chces nejake dalsi, musis znovu vyvolat vyhledavani s tim, ze mu reknes, kolik kesek ma od zacatku toho seznamu preskocit. Takze poprve si reknes, ze to chces od nulteho zaznamu. Podruhe ze to chces 50 zaznamu preskocit. Potreti ze chces preskocit 100 zaznamu, atd.

 

Jenze pokazde je to samostatne hledani, a pokazde se ten seznam kesi sestavuje znova! Netreba polemizovat nad efektivitou, proste je to tak.

 

Stazeni vetsiho mnozstvi kesi ale chvili trva. A tak se ti klidne stane, ze se v databazi kesi v pribehu stahovani neco zmeni! Neco co zpusobi, ze se najednou ten seznam na serveru seradi trochu jinak...

 

A tak to je i v tomto pripade. V pripade stahovani dle statu totiz GS usoudil, ze vychozi razeni toho seznamu bude podle favoritnich bodu. A ty se zjevne meni doslova pod rukama!

 

Kdyz si porovnas logy dvou stahovani toho Srbska, tak zjistis, ze se poradi kesi opravdu zmenilo. A diky tomu se ti stavalo, ze se nejaka keska, co jste stazena nebyla, prestehovala na tom seznamu dostatecne vzhuru, takze si ji preskocil. A naopak, diky tomu uz nejaka stazena keska odputovala v seznamu dolu, takze jsi ji stahl znova.

 

Tak jsem tam natvrdo nastavil razeni podle jineho kriteria, ktere by se takhle divoce menit nemelo, a uz to nezlobi.

[Arne1]

Blahopřeji !

To bych neřekl, že se zrovna v Srbsku toho tolik děje ! Já myslel, že tam chcípl pes...

Tento příspěvek byl upraven od Arne1: 12 duben 2019 - 9:15

[Kreten8]

Nevím, ale přijde mi, že můj problém trochu zapadnul, tak se připomínám : http://www.geocachin...e-7#entry570228

[Pontiac_CZ]

Jenze pokazde je to samostatne hledani, a pokazde se ten seznam kesi sestavuje znova! Netreba polemizovat nad efektivitou, proste je to tak.

 

To je k pláči. Já vím, že nechceš polemizovat, ale stejně by mě zajímal důvod této architektury. Aby jim lidi nestahovali moc keší? Od toho jsou ale spíš denní limity, tohle jim pouze pekelně zvýší počet dotazů do databáze plus zátěž na CPU, nějaký skript to musí před odesláním zpracovat, převést na XML atd.... No on se nám GS stejně nesvěří a budou si to stále látat po svém.

[gord]

Jenze pokazde je to samostatne hledani, a pokazde se ten seznam kesi sestavuje znova! Netreba polemizovat nad efektivitou, proste je to tak.

...

A tak to je i v tomto pripade. V pripade stahovani dle statu totiz GS usoudil, ze vychozi razeni toho seznamu bude podle favoritnich bodu. A ty se zjevne meni doslova pod rukama!

 

 

  Tohle snad zadny programator nemohl vymyslet (a udelat). To primo popira to strankovani! Poslal jsi jim to jako chybu? Zajimalo by me, co na takovou pripominku reknou.

 

Obdivuji te, ze jsi to odhalil, na tohle bych asi neprisel, protoze by me takova kravina ve snu nenapadla.

[HaLuMa]

On ten jejich úmysl není až tak nelogický. Nechtejí si mezi požadavky pamatovat stav. Jinak by si po prvním volání museli zapamatovat celý nahledaný výsledek, aby se k němu posléze mohli vrátit a pokračovat v něm. Museli by řešit identifikaci hledání (jestli je to pokračování starého, nebo hledání nové), museli by řešit životní cyklus (kdy to mohou smazat), atd. To celé klidně sežere na serveru více prostředků, než dobře implementované hledání volané pořád dokolečka.

 

Jen trochu nedomysleli to hledání nad měnícími daty... nebo možná jen zvolili pro ně menší zlo.

[Arne1]

a jak to dělali ve starém API ?

[LudekV]

To je běžný princip RESTful služeb. Jak píše HaLuMa, pokud je to udělané dobře a nad rozumnou databází, tak ten nový dotaz tolik nesežere a je to zřejmě lepší, než držet stav.

 

Mimochodem, to výchozí třídění je popsané v dokumentaci, ale logiku taky nechápu. Odobně bych tam dal podle GC kódu, ten se moc nemění :-)

distance+ if the query contains a location otherwise favorites-

[gord]

Ja vim proc to tak udelali, ze je to pro ne nejjednodussi. Timto postupem maji napr. na mape neuplnou sadu kesi v dane lokalite. Jiste, jde jen o hru, neni to nic fatalniho, ale stejne ...

[HaLuMa]

a jak to dělali ve starém API ?

 

Tam si prave vysledek hledani pamatovali a jinou funkci ses po vysledku prochazel.