87 odpovědí na toto téma

[mikeant]

Nestačilo by dobastlit export přírůstku dat v programu za období a importní skript na straně GG ?

 

Export přírůstků dobastlený už je, Luděk byl tak hodný a na můj podnět přidal filtr "Naposledy upraveno". Jen nějak nechápu, proč se následně při exportu do GPX exportují i WP Original location (které jsou tak nějak k ničemu ). Každopádně tímto způsobem lze aktualizovat GG z AD a mám již úspěšně odzkoušeno (a nepotřebuji ani připojení k PC - posílám si to změnové GPX mailem). Ovšem pořád to neřeší můj původní problém.

 

Myslím že bastlit HTTP server do AD je zbytečné.

[gord]

Co se vlastne exportuje? Jen polozky, ktere byly opravdu zmeneny nebo cela kes, u ktere doslo ke zmene?

 

Stale zustava problem v tom, ze importem prislusnych dat muzes prijit o data, ktera jsou v PC cerstvejsi. To je opravdu nutne resit skutecnou synchronizaci, jinak to nepujde.

[mikeant]

Co se vlastne exportuje? Jen polozky, ktere byly opravdu zmeneny nebo cela kes, u ktere doslo ke zmene?

 

Stale zustava problem v tom, ze importem prislusnych dat muzes prijit o data, ktera jsou v PC cerstvejsi. To je opravdu nutne resit skutecnou synchronizaci, jinak to nepujde.

 

Exportuje se samozřejmě celá keš. Trochu problém je, že se označí za změněnou i po pouhém otevření v AD. Čerstvost dat v GG je samozřejmě nutné ohlídat ručně, což pro mně není až takový problém (vždycky než něco zapíšu do GG, provedu import z AD). Nevyvracím, že skutečná synchronizace je do budoucna nutnost, ale za současné situace takovouto berličku vítám, protože než to někdo napíše, to mlže trvat i roky

 

Každopádně si stále myslím, že implementace HTTP serveru do AD je vcelku zbytečná, synchronizace se může provádět s DB zkopírovanou do PC. Moje gigová DB se přes MTP kopíruje necelou minutu, přes FTP je to asi na 4 minuty. Zase na druhou stranu by to odstranilo nutno kopírování celé DB oběma směry. Otázkou je, jak dlouho by trvala synchronizace přes HTTP při změně celé DB (např. po importu APQ).

[gord]

Zmena = zobrazeni ... to jsou mi veci, to by me nenapadlo Tim spis je nutne hlidat datum a cas zmeny jednotlivych hodnot.

[kolombo]

Já jsem si právě říkal, že kdyby byl nějaký systém záznamu změn v a:drake v mobilu, stačilo by jej vzít a aplikovat v GG.

 

Určitě by to bylo snažší, než web server a asi by se dalo více vypilovat co a jak má s daty dělat import v GG.

 

Ale samozřejmě, pokud by bylo a:drake API, kde by si GG, třeba podle logů na GC.COM, kontroloval změny v databázi přímo v mobilu a přenášel je do databáze GG, bylo by to báječné.

 

Jen si říkám, jestli to není zbytečně moc práce na to, kolik lidí to použije.

[LudekV]

Motivace pro moji úvahu byla několikerá:

1) řada lidí má problém s aDrakeSync přes MTP

2) hlavní práci by měl odvést plugin v GG

3) maximálně jednoduché pro BFU - ideálně tak, že si PC najde mobil atuomaticky (to nevím jak realizovat), v horším tak, že uživatel nastaví IP adresu telefonu (tu mu aD ukáže) v pluginu a pak už jen spustí synchronizaci

 

Pokud by a:Drake uměl pracovat jako server, pak plugin v GG může posílat jakékoli SQL dotazy a tím se otevře cesta k synchronizaci. Navíc by nebylo nutné přenášet celou databázi do PC.

Teď jde o to, zda se někdo ujme vývoje pluginu pro GG a jestli to celé není hloupost.

 

Jinak a:Drake zaznamenáva datum a čaas poslední změny a umí i export podle toho data. Jenže to je pro řadu uživatelů příliš složité a nedokážou to použít. Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).

[kolombo]

Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).

 

Kolombo to vůbec nehledal, protože mobil používá jako nouzovku, když někde je a má GPS doma. Nebo když potřebuje ověřit aktuální stav keše.

 

Automatické synchronizace ostrých a leckdy nezazálohovaných dat nemám tak úplně rád.

[gord]

Mne osobne pripada pripojeni pres HTTP server jako docela zajimava alternativa k MTP. K tomu, aby z PC bylo poslano nejake SQL, je treba vedet, co vlastne zadat. A to vi jedine aD. Jsem ochotny se na tom podilet. Asi by bylo dobre to napred prodiskutovat ze vsech pohledu treba v tom dokumentu o synchronizaci, co jsme si vyrikavali predchozi situaci.

[HaLuMa]

Aby to byla alternativa k MTP, nemel by tam fungovat i smer GG->AD ?

Tento příspěvek byl upraven od HaLuMa: 01 říjen 2015 - 15:03

[gord]

Synchronizaci chapu jako synchronizaci - tedy data obema smery.Je jasne, ze to je dost prace.

[mikeant]

Motivace pro moji úvahu byla několikerá:

1) řada lidí má problém s aDrakeSync přes MTP

2) hlavní práci by měl odvést plugin v GG

3) maximálně jednoduché pro BFU - ideálně tak, že si PC najde mobil atuomaticky (to nevím jak realizovat), v horším tak, že uživatel nastaví IP adresu telefonu (tu mu aD ukáže) v pluginu a pak už jen spustí synchronizaci

 

Pokud by a:Drake uměl pracovat jako server, pak plugin v GG může posílat jakékoli SQL dotazy a tím se otevře cesta k synchronizaci. Navíc by nebylo nutné přenášet celou databázi do PC.

Teď jde o to, zda se někdo ujme vývoje pluginu pro GG a jestli to celé není hloupost.

 

Jinak a:Drake zaznamenáva datum a čaas poslední změny a umí i export podle toho data. Jenže to je pro řadu uživatelů příliš složité a nedokážou to použít. Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).

 

1) On to není až tak problém synchronizace přes MTP, jako spíš problém to vůbec připojit, aby si adrakesync načetl potřebné. Já mu například (u připojení přes FTP) musel podvrhnout upravený adrake.ini, neboť adreakesync vyžaduje plné cesty.

 

2) souhlas

 

3) možná bych to doplnil o volby Nepřepisovat/přepsat pouze starší/přepsat vše či o možnost synchronizace pouze jedním směrem.

 

Přenášení celé databáze do PC by se dalo vyhnout, ovšem po celkové aktualizaci dat v GG by to na přenos celé db zpět do AD bylo. Otázkou je, o kolik by taková synchronizace byla pomalejší než zkopírování celé DB.

 

Nechápu, co je na vyfiltrování a exportu do GPX složité. Je to otázka pár kliknutí, vše je přehledné a jasné. Trošičku problém jsou výsledná vyexportovaná data (logy neobsahují údaje ze šablony, jsou exportovány i jen otevřené nezměněné keše, export obsahuje vcelku zbytečné WP "Original Location", ale to už se dá odladit při následném importu.

[gord]

Prenaseni cele databaze do PC je velmi vhodne se vyhnout. Databaze obsahuje prostorovy index, ktery zatim SQLIte na androidu nepodporuje. Po prenosu cele databaze z mobilu do PC je tedy tento index temer jiste poskozen. (Ano, jiste, lze jej po prenosu databaze vytvorit znovu.)

[mikeant]

Prenaseni cele databaze do PC je velmi vhodne se vyhnout. Databaze obsahuje prostorovy index, ktery zatim SQLIte na androidu nepodporuje. Po prenosu cele databaze z mobilu do PC je tedy tento index temer jiste poskozen. (Ano, jiste, lze jej po prenosu databaze vytvorit znovu.)

Nene, mám na mysli přenášení celé databáze z PC do mobilu... Přenos celé databáze do PC pouze pro účely rychlejší synchronizace, jako samostatné db, se kterou by se pracovalo odděleně. To by ovšem eliminoval webserver běžící v adrake

Tento příspěvek byl upraven od mikeant: 02 říjen 2015 - 10:30

[LudekV]

Přenos celé DB z PC do mobilu považuji za velmi vhodný, protože operace UPADE/INSERT v telefonu nejsou zrovna rychlé (pochopitelně záleží na výkonu telefonu a rychlosti SD karty) a nějaké masivnější změny je lepší udělat na PC s vyšším výkonem a nakopírovat pak jenom výsledek.

[HaLuMa]

Podle mne je tedy optimalni model pouzivani (alespon pro mne):

• ziskani zmen spachanych Adrakem na databazi v mobilu
• pokusit se je nekonfliktne promitnout do GG
• vyslednou databazi naladovat do mobilu

[mh.mail]

Já bych se tedy přimluvil za obousměrnou implementaci INSERT/UPDATE, protože to pro malé změny může být efektivnější (i přes pomalost) než kopírovat vždy celou databázi. Ale ten model, co popisuje HaLuMa, bych implementoval taky (pro větší změny).

[mikeant]

 

Podle mne je tedy optimalni model pouzivani (alespon pro mne):

• ziskani zmen spachanych Adrakem na databazi v mobilu
• pokusit se je nekonfliktne promitnout do GG
• vyslednou databazi naladovat do mobilu

 

 

Pod to se podepíšu, přičemž v jakés-takés podobě jsou první a poslední krok vyřešeny (export GPX, ruční překopírování). Samozřejmě kdyby to proběhlo sofistikovaně v jediném kroku (alespoň tedy první a druhý bod), budu na vrcholu blaha.

 

PS: dnes jsem v GGP zvládnul "Hello world"

[gord]

V tom GPX z aD by musely byt navic doplneny jeho vlastni informace o tom, kdy byla ktera polozka v aD zmenena. Pak uz by bylo mozne alespon kontrolovat, zda nedochazi ke konfliktu - pokud o zmenu polozky zmenene v DB od posledni synchronizace.

[HaLuMa]

Tak on hlavne v GPX chybi ten timestamp z databaze o tom, kdy byl zaznam naposledy modifikovan. Coz je pro synchronizacni ulohu fatalni problem.

[gord]

Ano, to jsem mel na mysli temi doplnenymi informacemi. Muselo by to tedy byt podobne rozsireni GPX, jako mas ty pro GG, ale jeste o ty polozky s casem zmeny, aby to ten synchronizacni plugin mohl pouzit pro kontroly.