Criar campos com identificador único/status para os jobs

[gmgall]

Dei uma olhada no modelo para já ir pensando como transformar o que vai ser escrito lá num job num dos clusters e identifiquei a necessidade de termos:

• um identificador único para cada job;
• um campo para o status do job.

Se entendi corretamente, a tabela que eu preciso consultar seria a experiment:

Eu poderia usar a chave primária idexperiment como o identificador único? Seria uma boa prática?

Com relação ao campo de status: acho que ele é necessário para eu fazer algo como

SELECT * FROM experiment WHERE status = 'não submetido'

a cada execução do meu programa. Depois de terminado, eu atualizaria o campo status para algo como terminado; então, na próxima execução, só leria os jobs que ainda precisam ser submetidos.

Talvez essa não seja a melhor forma de fazer e vocês tenham uma ideia melhor. Criei essa issue para a gente ir discutindo isso.

[FelipeSBarros]

Tentarei trazer os comentários do slack para cá.

Com relação à sua pergunta:

Eu poderia usar a chave primária idexperiment como o identificador único? Seria uma boa prática?

O Luis Alexandre respondeu positivamente:

Sim, penso que pode usar o mesmo valor da chave primária "idexperiment".

Além disso, inclui a proposta de ter data e hora de inicio, bem como de fim do experimento, como sugerido pelo Luis Alexandre no link acima, e o status como você sugeriu. Tais mudanças estão no commit: 461cb20

Contudo, ainda acho que não estamos fechados nessa issue, pois imagno que vc esteja preocupado em saber não apenas se o experimento teve inicio, fim com ou sem sucesso, mas tabmém, e principalmente quando não houve sucesso, em que algoritmos/espécie houve erro. Estou correto, @gmgall ?

[gmgall]

Acho que a gente pode encarrar essa issue de 2 formas:

1. Se desejarmos só avisar que um erro ocorreu, basta escrever no campo status o texto do erro do jeito que ele for escrito na saída de erros do gerenciador de filas dos clusters. Nesse caso o usuário tentaria novamente ou entraria em contato conosco para ver o que ocorreu. Nessa perspectiva, essa issue está resolvida.
2. Se desejarmos informar exatamente em que algoritmos/espécies o erro ocorreu, podemos usar o campo status também, mas acho que os scripts de modelagem não estão prontos para gerar mensagens de erro significativas do jeito que estão hoje. Pense na última vez que teve um erro durante uma modelagem. As mensagens deixavam claro em qual algoritmo ou espécie a execução parou? Ou era necessário ver que arquivos foram escritos etc para descobrir? Para a gente gerar mensagens de erro com esse grau de exatidão, acho que teremos que colocar várias checagens nos scripts e dispará-las com stop(), message() e warning(). Nessa perspectiva, ainda temos muito o que conversar. Não sei se nessa issue ou numa nova lá no Model-R/Back-end.

Acho que (2) é o ideal, mas vai dar - muito? 🤔- mais trabalho.

---

Dica: se você referenciar a issue na mensagem de commit, aparece um link para o commit aqui. Exemplo: Model-R/Back-end#1 foi referenciado na mensagem de Model-R/Back-end@6a1378e.

[FelipeSBarros]

@gmgall e Luis Alexandre, conforme ví nas conversa do slack ( aqui e aqui ), estamos de acordo em implementar a opção 1:

1. Se desejarmos só avisar que um erro ocorreu, basta escrever no campo status o texto do erro do jeito que ele for escrito na saída de erros do gerenciador de filas dos clusters. Nesse caso o usuário tentaria novamente ou entraria em contato conosco para ver o que ocorreu. Nessa perspectiva, essa issue está resolvida.

Deixando a opção 2, para quando e se oportuno.

[gmgall]

Acho que se nem é dúvida, @FelipeSBarros. É o ideal. Devemos mirar em (2), mas talvez só acertemos em (1).

Digo isso pelo seguinte: pense no quanto o código de Model-R/Back-end vai mudar ainda: eu quero implementar paralelismo por algoritmo, você quer fazê-lo escrever rasters etc no banco, a @AndreaSanchezTapia acho que quer mexer na parte de projeções...

Deixe o campo status lá. A exatidão do que escreveremos nele dependerá do quanto andarmos na direção de (2).

[AndreaSanchezTapia]

Como isso se faz, Guilherme? Na minha cabeça é checar na hora de escrever os arquivos - se o objeto a ser escrito é NULL, ou se sua longitude/suas dimensões são nulas, ou se os arquivos existem ou não (file.exists()). Gerando messagens de warning() e não de stop, porque ter que recomeçar a cada vez (╯°□°)╯︵ ┻━┻

(Não sei se o comportamento de anunciar que houve warnings e que para vé-los é preciso teclar warnings() é espontâneo)

A outra seria fazer um log que bote tudo o que a interface posta na tela e conseguir ler o log. Meu jeito botânico de fazer isso é criar um arquivo com sink(), que duplica o output da consola num arquivo, para ver o que houve. Nunca usei message(), apenas botava um cat() ou um print() para ficar constância no output do sink(). Com o tempo a única mensagem que ficou foram os "DONE" mas acho que os pontos dos scripts onde estão essas mensagens ainda são mais ou menos os pontos onde podemos checar.

[gmgall]

A funcionalidade do sink() já é oferecida pelos gerenciadores de jobs dos clusters. Em geral, é criado um arquivo com o que foi escrito na stdout e outro com o que foi escrito na stderr (saídas padrão e de erros, respectivamente).

Meu ponto é: as mensagens são significativas para o usuário final? Informar erros como

Error in na.fail.default(list(`sdmdata_train$pa` = c(1, 1, 1, 1, 1, 1,  :  missing values in object Calls: dismo.mod ... model.frame.default -> <Anonymous> -> na.fail.default Execução interrompida

é de alguma valia?

O ideal parece-me ter algo como erro na espécie X, algoritmo de modelagem Y: detalhes do erro. Daria para fazer isso disparando exceções, mas nem sei se o R as tem. Vou estudar isso no livro do Wickham para ter uma opinião melhor.

---

Acho que a gente divergiu do assunto original da issue aqui também. A questão original, como ter um identificador único para os jobs, parece-me resolvida: usaremos idexperiment. O quão informativo será o que vai ser escrito em status (ou seja, o quão informativas serão nossas mensagens de erro) parece-me que seria melhor discutido numa issue em Back-end ou Middleware. Concordam?