104 odpovědí na toto téma

[VasaM]

Nějak chybí odkaz...

[Nemo02]

Vypadá to dobře. Jenom to bude chvili trvat, než mi to zaktualizuje zkušební databázi. P.S.: Retract = 2 publikační logy

[mpik]

Právě proto jsem to dal nejdřív sem. V případě retractu - který počítat? První nebo druhý? mě připadá lepší ten druhý.

[Nemo02]

Vyhodí dva tagy DatePublished.

[mpik]

Tak to se ošetřit dá. Ale jinak je to ale přece správně, ta keš byla publikovaná dvakrát. Taky jsme tu takovou měli. Publikovaná asi tak 3 minuty, což ale stačilo na to, aby FTFkaři vyrazili a následně zjistili, že ji nemohou zalogovat. Přehlédnutá kolize, kde by ji nikdo nečekal.

[Nemo02]

No jo, to mi nevadí, ale které je správnější? Tady FTFkaři nestačili vyrazit. Jinak nejstarší keš s publikačním logem mám GCQ7QC z 21.8.2005.

[mpik]

To je otázka, které je správnější. Podle mě to druhé, protože to první znamená puštění omylem. Případné nálezy mezi nimi jsou předpublikační. Jak to řešit ? Buď automaticky, že s tím něco udělám, nebo ručně - jeden z nich smáznout. Mimochodem, stažením logů přes API přímo z geogetu s omezením počtu a refine se publikační logy smažou. Zatím. Tag už pochopitelně zůstane. Pokud v nové verzi GG bude Publish log brán jako důležitý, ponechaný, budu moci ze svého pluginu to čištění vyhodit. Nevím jak s tím pracuje, mohlo by to možná jít mimo databázové akce, ale nevím.

[kolombo]

pozorjed napsal/a:
Ad Kolombo: TAG = rychlé řešení. Nevýhoda, pokud se objeví 2 řešení stejného problému a názvy TAGů budou rozdílné. Následně je uzavřena cesta něco dodělat do GG (např. přidat do exportu GPX), protože mohou existovat 2 rozdílné TAGy pro totéž. Z tohoto důvodu je lepší mít jednoznačnou databázovou položku.

To by se mohly vyrábět jen jedny velikosti šroubů a matic, aby to někdo nepopletl :-)

Prostě musíš používat řešení A a ne B, když nejsou zaměnitelná ...

Pak je ještě možnost ten TAG prostě normalizovat pro všechna řešení s datem publikace.

[mpik]

Pak je ještě možnost ten TAG prostě normalizovat pro všechna řešení s datem publikace.

Protože jsem autorem prvního nástřelu, zajímalo by mě jak ten tag normalizovat. Aby vyhovoval všem. protože já sám ještě nevím, jak to využiju, zatím jsem na tom dál nedělal.

[kolombo]

mpik napsal/a:

Pak je ještě možnost ten TAG prostě normalizovat pro všechna řešení s datem publikace.

Protože jsem autorem prvního nástřelu, zajímalo by mě jak ten tag normalizovat. Aby vyhovoval všem. protože já sám ještě nevím, jak to využiju, zatím jsem na tom dál nedělal.

Dopiš ho do dokumentaci ke GeoGetu, zkus se domluvit třeba s Peťulinkou1, ta na té dokumentaci dělá, kam to tam dopsat a přidej tam to svoje řešení, aby bylo jasné, jak to dělat, aby to bylo kompatibilní.

A pokud přidáš makro na web GG a doplníš ho popisem, tak asi nebude důvod dělat to jinak, ne ?

[mpik]

No, počkám pár dní (tlačí mě práce, ale nedalo mi to nezkusit to napsat). Udělám tam asi jen poslední Publish log (při retractu), pokusím se asi o vizualizaci, možná i o využití ve statistikách, pokud to nepůjde nějak jednoduše použít v GGstatu. A na Ararat ho dám.

[pozorjed]

kolombo napsal/a:
Pak je ještě možnost ten TAG prostě normalizovat pro všechna řešení s datem publikace.

To by se právě zajistilo tím, že by bylo přímo v datovém modelu Geogetu. Jaké máš zkušenosti s databázemi, že máš takové "zajímavé" postřehy.

[kolombo]

pozorjed napsal/a:

kolombo napsal/a:
Pak je ještě možnost ten TAG prostě normalizovat pro všechna řešení s datem publikace.

To by se právě zajistilo tím, že by bylo přímo v datovém modelu Geogetu. Jaké máš zkušenosti s databázemi, že máš takové "zajímavé" postřehy.

HaLuMa sem napsal tohle:
Fakt se mi nechce delat dalsi verzi databaze jen kvuli takove pitomine. To si musi pockat na neco vetsiho.

A nikdo jiný s databází hýbat nemůže.

Myslíš databázi děrných pásek nebo děrných štítků ?

[pozorjed]

kolombo napsal/a:
Myslíš databázi děrných pásek nebo děrných štítků ?

Tím se to vysvětluje , zkus se posunout trochu dál, najdi na wiki heslo "SQL".

Datový model Geogetu byl rozšířen např. o položku geocache.dtupdate2 . Svět se nezbořil, dokonce i Kolombo to přežil (nebo si nevšiml?). Ve vláknu jsem napsal, že to není potřeba v nejbližší verzi, ale myslet na to, až se bude rozšiřovat datová struktura, aby se provedlo najednou.

Už podruhé jsi nepozorně četl - doporučuji Ti psát méně příspěvků, aby jsi stíhal vnímat, na co odpovídáš, děkuji.

[mpik]

Vím, jaké problémy mohou nastat při změně struktury databáze. Minimálně takové, že někdo bude používat starou verzi a buď mu něco nebude fungovat, nebo dokonce se mu databáze rozsype. I když vhodně použité SQL dost tyto problémy minimalizuje. Já dělal ještě s Dbase2 a Fox+. Ještě na osmipalcových disketách. Takže bych opravdu byl pro to, aby se případné doplnění položky do struktury svezlo s nějakým větším updatem a teď to nechalo být. Nestojí to za případné problémy. Do tagů se to dá dostat poměrně bezproblémově, kdyby byla položka přímo v databázi, dalo by se to dostat i do ní, třeba i překopírováním z tagů, aby se to nemuselo znovu stahovat. I když nejlepší by bylo, kdyby tuto položku začal poskytovat přímo Groundspeak a třídil podle ní na webu. Vůbec bych se nezlobil, že moje práce byla zbytečná. Ale toho se asi nedočkáme.

[gord]

Pro zacatek staci dat Jmeno kategorie TAGu do config.pas a tam si to muze kazdy snadno zmenit.

[kolombo]

pozorjed napsal/a:

kolombo napsal/a:
Myslíš databázi děrných pásek nebo děrných štítků ?

Tím se to vysvětluje , zkus se posunout trochu dál, najdi na wiki heslo "SQL".

Datový model Geogetu byl rozšířen např. o položku geocache.dtupdate2 . Svět se nezbořil, dokonce i Kolombo to přežil (nebo si nevšiml?). Ve vláknu jsem napsal, že to není potřeba v nejbližší verzi, ale myslet na to, až se bude rozšiřovat datová struktura, aby se provedlo najednou.

Už podruhé jsi nepozorně četl - doporučuji Ti psát méně příspěvků, aby jsi stíhal vnímat, na co odpovídáš, děkuji.

Díky téhle odpovědi jsi spadl do škatulky shaman3.

A. Nepoznáš vtip.
B. O tom, jak se mění databáze rozhoduje HaLuMa a ten už se vyjádřil. Pokud vím, tak databáze se měnila zatím jen 2x až 3x, přesně spočítané to nemám.
C. Myslím, že jsem už nějaké SQL viděl, ale neprogramuji ho. Já jsem ten, co má šroubovák.

[pozorjed]

kolombo napsal/a:
Díky téhle odpovědi jsi spadl do škatulky shaman3.

??? zkus lépe vysvětlit, nevím co to je. Pro mě jsi v kategorii jalový přispěvovatel na kdeco bez hlubší úvahy. Polovina příspěvků bez informační hodnoty, vůbec neměla být napsaná. Prostě "diskutér".

A. Nepoznáš vtip.

Nápodobně. Ty ani neumíš odpověd na otázku. A když už, odpovědi popleteš . Buď neudržíš myšlenku a uprostřed psaní ji zapomeneš nebo prostě nerozumíš tomu o čem chceš psát, ale nutkání se k něčemu vyjádřit zvítězí nad zdravým rozumem.

B. O tom, jak se mění databáze rozhoduje HaLuMa a ten už se vyjádřil. Pokud vím, tak databáze se měnila zatím jen 2x až 3x, přesně spočítané to nemám.

Ano, v tom případě nechápu, proč se k tomu stále vyjadřuješ. Myslím, že příspěvky byly srozumitelné a pochopitelné. Nikde jsem nepsal, že bez této změny struktury se nedá dále pracovat, jen že by to pomohlo a v čemu by to sloužilo. A proč je lepší mít v databázi přímo a ne jen v TAGu. HaLuMa se vyjádřil, že vede v patrnosti, nezavrhuje, ale nebude zapracovávat hned.

C. Myslím, že jsem už nějaké SQL viděl, ale neprogramuji ho. Já jsem ten, co má šroubovák.

Tedy mechanický robot Karel - jdi doleva, až narazíš na zeď, otoč se o 90 stupňů a jdi dál. To už dnes bohužel nestačí, i programování se posunulo kousek dál .

Pokud chceš, nabízím Ti základní kurz kolem SQL, návrhu datové struktury ... můžeme to projít, možná to pomůže a bude to užitečnější než pár posledních příspěvků.

[kolombo]

pozorjed napsal/a:

C. Myslím, že jsem už nějaké SQL viděl, ale neprogramuji ho. Já jsem ten, co má šroubovák.

Tedy mechanický robot Karel - jdi doleva, až narazíš na zeď, otoč se o 90 stupňů a jdi dál. To už dnes bohužel nestačí, i programování se posunulo kousek dál .

Přijde mi, že Tvoje vtip není.

Každý nemůže být jen programátor, pak tu ještě musí být pár lidí, co ví, jak to zapojit aby to fungovalo. Karla GC14HG3 odloveného mám, to je vysoký level programování :-)

[Nemo02]

Dokončeno. Projel jsem celou svoji databázi. Jenom GC14WV8 (11 301 Fount it, 109 Owner Maintenance a 1 Publish Listing) jsem si musel dopsat ručně. Diky za plugin.