GSAK - Noções básicas

Existe alguma macro que, para as caches "com coordenada alterada", mostre a distância entre a coordenada original e a coordenada alterada?

Obrigado

Existe alguma macro que, para as caches "com coordenada alterada", mostre a distância entre a coordenada original e a coordenada alterada?

Obrigado

precisas de macro porque queres fazer isso para muitas em simultâneo,certo?
No menu onde inseres as coordenadas corrigidas aparece automaticamente a distância...

precisas de macro porque queres fazer isso para muitas em simultâneo,certo?

Sim, isso mesmo.

Chato...As actualizações de logs demoram tempo, mas não haveria problemas se com frequência não dessem erro o que implica a perca de tudo...

Chato...As actualizações de logs demoram tempo, mas não haveria problemas se com frequência não dessem erro o que implica a perca de tudo...

Já reportaste no fórum do GSAK? Normalmente aparecem soluções rapidamente.

Chato...As actualizações de logs demoram tempo, mas não haveria problemas se com frequência não dessem erro o que implica a perca de tudo...

Já reportaste no fórum do GSAK? Normalmente aparecem soluções rapidamente.

Tenho de fazer isso. A ver se sistematizo os meus "problemas" que não deverão ser típicos de uma utilização "normal" do GSAK...
Por exemplo não consigo apagar logs na BD principal (que está com 12M de logs).
Assim para recuperar logs retroactivos que não são recuperados normalmente pelas PQ ou pelo Get Logs normal (feito sobre a posição já com logs), tem de se apagar todos os logs da cache e depois o "All Logs (those not already in database)" já recupera tudo.
Se tento executar o Purge Logs (com as opções para apagar tudo) fico pendurado sem resposta (já fiz uma experiência em que só mandei o GSAK abaixo após umas horas valentes...). Assim tenho de mover as caches para uma BD auxiliar, fazer depois o Purge (muito rápido mesmo para volumetrias elevadas), atualizar os logs todos e depois voltar a mover para a BD principal. Funciona mas com um acréscimo de tempo devidos aos dois moves completamente desnecessários...e com uma data de passos manuais que se não demoram muito individualmente provocam muitas pausas indesejáveis...

Get Logs - Those not in database
didn't work if the only missing logs are very old logs (to get these logs need to delete all first)


Purge Logs
didn't work for large database with million logs (keep frozen for hours/days)

Get Logs - Those not in database
didn't work if the only missing logs are very old logs (to get these logs need to delete all first)

Sim. Está claro. Por isso é que a minha metodologia é
Actualizar via PQ.
Comparar com o referencial Project-GC (antes com o IAAN).
Se o GSAK tiver menos logs fazer primeiro um GetLogs simples que resolve os casos em que a questão é apenas ter havido mais de 5 logs na semana e menos de 30 (sem retroactividade).
Se continuar com logs a menos partir para o Purge Logs e Get Logs Total (o que implica o tal move entre BD e uma actualização demorada que por vezes dá erro...)
Se o GSAK tiver mais logs na maior parte dos casos até está bem e mais actualizado do que o Project-GC, mas fica sempre a dúvida se não correspondem a logs que foram apagados...Assim e especialmente se a data que tenho no GSAK com referência ao último refresh global tiver já algum tempo faço também o ciclo Purge Logs e Get Logs Total. Mesmo que até estivesse bem fico com os logs refrescados.
Por último...não tenho forma de detectar se houve alteração de logs e como não tenho capacidade pare refrescar periodicamente os logs de todas as caches é aí que posso/tenho com certeza registos menos correctos no GSAK...

Purge Logs
didn't work for large database with million logs (keep frozen for hours/days)

Sim eu vi isso. Mas para mim faz sentido se estivéssemos a falar em apagar todos os logs e não umas centenas de milhar ligados a umas centenas de caches que é normalmente o que é necessário. É suposto o purge ir por chave e não encontro grandes explicações para que o GSAK consiga gerir os moves (que implica deletes...) entre BD's e não consiga fazer o delete dos logs...Já estive tentado a fazer o delete directamente sobre as tabelas mas tenho receio de ficar com incoerências na BD.
Teria de apagar os registos em 3 tabelas e fazer um update na tabela Caches...



edit: O problema tem mesmo a ver com o tamanho total da BD e não com o número de logs a apagar. Não consigo sequer apagar um log de uma única cache

A questão de recuperar os logs com datas retroactivas é muito chata...
Posição desta semana de comparação entre o meu GSAK e a posição extraída do Project-GC para todos os casos em que tenho menos logs e já depois de fazer o get dos últimos logs (those not already in database) [o que é uma grande mentira conforme está assumido pelo Clyde...]

Tenho 474 logs a menos em 454 caches que no total têm mais de 300k logs....

A única forma que tenho de garantir que recupero mesmo os logs todos é apagar todos os logs e fazer novamente get de todos (agora sim a tal opção de recuperar todos já funciona bem...) o que para este volume ainda é uma operação para demorar umas horas valentes com a agravante que por vezes o processo pode ficar parado à espera de um OK manual após um conjunto de retrys sem sucesso ou em casos raros mas que acontecem pode dar erro e perder-se tudo...
Na informática há a regra dos 80/20 mas no caso estamos a falar aí de 90/10...adicionado os casos em que sou em que tenho mais logs mas nunca tenho a certeza se faltam no Project-GC ou se foram logs apagados e em que a única forma segura é fazer o mesmo (apagar/carregar) passa a 95/5...
Ou seja embora seja fundamentalmente trabalho de processamento requer acompanhamento periódico e indisponibiliza a utilização do GSAK...
Não compensa de todo e só o comecei a fazer por contraponto aos problemas de actualização do IAAN...
...e porque no entretanto fiquei "viciado" em ter o GSAK com uma posição o mais correcta possível

edit: Tudo seria tão mais simples se na origem se mantivesse um timestamp da alteração do log e se a API permitisse recuperar logs por essa via...

Um processo bastante mais rápido é o acerto do detalhe de favoritos.
Depois de garantir que estou mais certo do que o Project-GC a nível de total de favoritos é comparar com o detalhe que tenho,
Diferenças em 378 caches variando entre -5 e +2 favoritos.
Agora é recuperar os ~22k favoritos envolvidos.
Tenho de investir a sério numa macro para automatizar isto...