Ticket #1312 (closed defeito: fixed)

Opened 9 years ago

Last modified 9 years ago

Pesquisa no arquivamento local não funciona

Reported by: kolling Owned by: kolling
Priority: alta Milestone: Expresso 2.2
Component: ExpressoMail Version: branch 2.2
Severity: grave Keywords: SERPRO 2.2 UNIFICA pesquisa data arquivamento local
Cc: WorkGroup: Gestão de Integração

Description (last modified by diogenesduarte) (diff)

Removido código da pesquisa no arquivamento local.

Change History

comment:1 Changed 9 years ago by kolling

  • Owner changed from alguem to kolling
  • Priority changed from normal to alta
  • Summary changed from Pesquisa por data no arquivamento local não funciona to Pesquisa no arquivamento local não funciona
  • Description modified (diff)
  • Severity changed from pequena to grave

O problema é um pouco maior do que se pensava, qualquer busca no arquivamento local não funciona mais. Problema causado por implementação do ticket #428 que desconsidera completamente o arquivamento local.

Alguma idéia de como integrar busca no arquivamento local com essa implementação?

comment:2 Changed 9 years ago by kolling

Algumas sugestões:

1 - Realizar a pesquisa local antes da pesquisa no imap, enviar os resultados da pesquisa do arquivamento local para o servidor, que fará a ordenação/paginação; 2 - Realizar a pesquisa local onde era originalmente, e paginar após a paginação da pesquisa no imap; 3 - Realizar a pesquisa local e paginar independentemente da paginação da pesquisa no imap, possivelmente até abrindo outra aba com os resultados da pesquisa no arquivamento local.

Mais alguma sugestão?

comment:3 Changed 9 years ago by zapa

Mário,

Não é somente recolocar o código anterior? Porque há necessidade de refazer?

comment:4 follow-up: ↓ 6 Changed 9 years ago by amuller

Eu acho melhor deixar separado na visualização os locais e não locais. Porque se o servidor tiver que esperar por resultado da busca local a coisa vai ficar complicada.

comment:5 Changed 9 years ago by zapa

Pelos testes, o tempo de pesquisa no Arquivamento Local é insignificante, ou seja

pelo tamanho do meu Arquivamento ele é até mais rápido que o IMAP.

comment:6 in reply to: ↑ 4 Changed 9 years ago by kolling

Replying to amuller:

Eu acho melhor deixar separado na visualização os locais e não locais. Porque se o servidor tiver que esperar por resultado da busca local a coisa vai ficar complicada.

O problema não é nem o tempo da busca no arquivamento local, mas o overhead de enviar os resultados da consulta local para o servidor processar (ordenar e paginar).

comment:7 Changed 9 years ago by zapa

Proponho 2 alternativas, pelo colocado pelo Mário a 2 seria + fácil.

  1. Na pesquisa, o usuário poderá somente marcar pastas Imap ou Locais, nunca as duas.
  1. Conforme falado, abrir o resultado da pesquisa do AL(bem identidicada) em outra aba.

comment:8 Changed 9 years ago by amuller

Minha preocupação não era o tempo, mas a complexidade do sistema mesmo. Acho que o servidor PHP não devia nem saber da existência de informações locais.

Até porque juntar os locais e não locais na mesma busca vai trazer um monte de mal entendidos pelo usuário. Como por exemplo, a busca ser diferente em máquinas diferentes.

comment:9 follow-up: ↓ 10 Changed 9 years ago by diogenesduarte

O resultado da busca não poderia estar todo em uma session? Assim faríamos uma vez a busca local, submeteríamos para o servidor, ele ordenava tudo direitinho e jogava na session, assim toda vez que uma página fosse requisitada, é só ir na session e pegar esse array.

Para que o usuário não fique fazendo inúmeras buscas prejudicando o servidor, limitaríamos a ele poder fazer apenas duas buscas simultâneas por exemplo, caso fizesse a terceira, a primeira não valia mais e era fechada...

As informações por mensagens são poucas(id, assunto, flags), acredito que não será comum sessions gigantes principalmente porque ninguém faz busca para vir a caixa toda, mas se isso ocorrer, podemos tratar limitando o tempo de atividade delas. Uma busca feita a mais de X minutos que não foi utilizada(navegação entre as páginas), teria que ser refeita caso o usuário requisitasse outra página.

O que vocês acham?

comment:10 in reply to: ↑ 9 Changed 9 years ago by amuller

Replying to diogenesduarte:

O resultado da busca não poderia estar todo em uma session? O que vocês acham?

Eu acho que pode ser interessante guardar em algum lugar. Mas na session não.

comment:11 follow-up: ↓ 12 Changed 9 years ago by diogenesduarte

Inicialmente eu pense que poderia ser localmente... Só que vai ter que diferenciar a implementação para quem não utiliza mensagens locais, pois para gravar dados na máquina do usuário via javascript creio que só usando gears...

comment:12 in reply to: ↑ 11 Changed 9 years ago by kolling

Replying to diogenesduarte:

Inicialmente eu pense que poderia ser localmente... Só que vai ter que diferenciar a implementação para quem não utiliza mensagens locais, pois para gravar dados na máquina do usuário via javascript creio que só usando gears...

Esse caso seria mais complicado de implementar.

O mais fácil, provavelmente seria a alternativa 1. Colocando as consultas na session esse overhead diminuiria, mas traria outros problemas. Principalmente o impacto no tamanho da session, o que geraria a necessidade de implementar um gerenciamento para a persistência da pesquisa na session.

A terceira alternativa é dividir os resultados da consulta, criando abas diferentes, identificadas diferentemente para os resultados da pesquisa no imap e no arquivamento local. Eu comecei a testar esta abordagem. Não pareceu ser tão complexa de implementar e não necessitaria de alterações no PHP.

comment:13 follow-up: ↓ 14 Changed 9 years ago by diogenesduarte

  • Description modified (diff)

Acho que não fica legal para o usuário fazer uma busca e o resultado vir dividido em duas abas, podendo ter cada uma das abas, n páginas. Se o tamanho da session implica em não usar essa solução, eu votaria como melhor opção então deixar como está para usuários que não usem AL e para o usuário que esteja usando, usar uma tabela temporária para armazenar as buscas, ao invés da session.

Dá inclusive para pensarmos em fazer coisas interessantes do tipo cache de buscas, aí caso ele faça a mesma busca dentro de um intervalo curto de tempo não precisa passar por toda a rotina de novo... Mas aí é outro ticket...

comment:14 in reply to: ↑ 13 Changed 9 years ago by kolling

Replying to diogenesduarte:

Se o tamanho da session implica em não usar essa solução, eu votaria como melhor opção então deixar como está para usuários que não usem AL e para o usuário que esteja usando, usar uma tabela temporária para armazenar as buscas, ao invés da session.

Ok, mas não resolve o problema da paginação, que é feita no PHP, já que todos os resultados da consulta no AL terão que ser transferidos para o servidor de qualquer maneira. Eu prefiro não enviar para o servidor.

comment:15 Changed 9 years ago by diogenesduarte

Hum... Verdade, não tinha pensado nisso... A paginação seria via javascript... Mas aí o processamento seria muito grande no cliente. Será que não dá mesmo pra jogar isso na session? Bota para o usuário só poder fazer uma pesquisa por vez e para expirar com o tempo... Se for o caso bota um limite de 500 mensagens no máximo por busca...

Acho que separar em duas abas só em último caso mesmo, pois acho ruim para o usuário abrir duas abas ao pedir uma busca

comment:16 Changed 9 years ago by amuller

Guarda em um arquivo e deixa só o nome do arquivo na session, ainda assim é menos pior. Apesar de ainda ser contra esse tipo de coisa.

comment:17 Changed 9 years ago by amuller

Dá pra colocar tudo numa aba só sem ter que mandar para o servidor.

comment:18 follow-up: ↓ 19 Changed 9 years ago by diogenesduarte

O problema, como kolling disse, é paginar. Vamos ter que colocar toda a lógica no javascript em cima do montante. Isso eu acho que vai onerar a máquina do usuário ao fazer merge com as mensagens locais, ordenar e paginar. Além disso, teremos duas implementações, pois o usuário precisa ter o gears, caso contrário como vamos salvar arquivos na máquina dele?

comment:19 in reply to: ↑ 18 ; follow-up: ↓ 21 Changed 9 years ago by amuller

Replying to diogenesduarte:

Além disso, teremos duas implementações, pois o usuário precisa ter o gears, caso contrário como vamos salvar arquivos na máquina dele?

Você poderia explicar melhor essa questão?

comment:20 follow-up: ↓ 22 Changed 9 years ago by zapa

E se tirarmos a paginação da pesquisa e limitarmos a quantidade(poderia ser configurável)? Acredito que o trabalho para juntar as duas pesquisas e pagina-las não vale o esforço, pois o usuário quer é achar algum email, se estiver em uma única página melhor.

comment:21 in reply to: ↑ 19 Changed 9 years ago by diogenesduarte

Duas implementações, pois se o usuário possuir gears, usa o gears e pagina tudo localmente via javascript, mas se ele não tiver, faz tudo como já está implementado, no servidor...

Replying to amuller:

Replying to diogenesduarte:

Além disso, teremos duas implementações, pois o usuário precisa ter o gears, caso contrário como vamos salvar arquivos na máquina dele?

Você poderia explicar melhor essa questão?

comment:22 in reply to: ↑ 20 Changed 9 years ago by diogenesduarte

Realmente, o esforço seria grande, principalmente se não armazenarmos a busca na session.

Replying to zapa:

E se tirarmos a paginação da pesquisa e limitarmos a quantidade(poderia ser configurável)? Acredito que o trabalho para juntar as duas pesquisas e pagina-las não vale o esforço, pois o usuário quer é achar algum email, se estiver em uma única página melhor.

comment:23 follow-up: ↓ 24 Changed 9 years ago by amuller

Tem o problema do usuário querer fazer uma busca por exemplo para apagar todas as mensagens que casam com determinado padrão. Por exemplo quero apagar todos os 5 mil emails com "Confirmação de leitura" no assunto. Isso não pode ser feito se não tiver paginação na busca.

A session não serve pra isso. Session não é cache. Fora o fato de você armazenar um monte de páginas na session que podem nunca ser usadas, e você vai deixar lá para carregar e descarregar em todas as requisições.

comment:24 in reply to: ↑ 23 Changed 9 years ago by diogenesduarte

Replying to amuller:

Tem o problema do usuário querer fazer uma busca por exemplo para apagar todas as mensagens que casam com determinado padrão. Por exemplo quero apagar todos os 5 mil emails com "Confirmação de leitura" no assunto. Isso não pode ser feito se não tiver paginação na busca.

Se o máximo for 200, ele faz uma busca, vem 200, ele apaga, depois faz a mesma busca... Acho que paginação não ajuda tanto nesse caso, e até atrapalha em outro caso, pois se paginar de 50 em 50 e ele quiser apagar 80, ele vai fazer uma navegação a mais.

A session não serve pra isso. Session não é cache. Fora o fato de você armazenar um monte de páginas na session que podem nunca ser usadas, e você vai deixar lá para carregar e descarregar em todas as requisições.

Concordo que session não é cache, mas a idéia não é cachear todas as buscas. Usá-la como repositório auxiliar é uma forma que torna viável a busca com paginação e não vejo gerar problemas graves se o uso for controlado com um limite máximo de resultados(que pode ser alto), com um tempo de expiração(caso ele fique muito tempo sem navegar entre as pastas a session é removida e ele terá que refazer a busca caso queira ir para outra página) e com a limitação de uma busca por vez(ele não poderá fazer N buscas, a segunda remove o conteúdo da primeira na session e a aba da busca anterior é fechada).

comment:25 follow-up: ↓ 26 Changed 9 years ago by zapa

Diogenes,

Vocês já tem isto implementado? Como funciona?

comment:26 in reply to: ↑ 25 Changed 9 years ago by diogenesduarte

Zapa, na verdade aqui está funcionando sem a paginação mesmo, a paginação veio em uma revisão posterior a revisão que colocamos em produção. Essa idéia é só minha opinião da melhor forma para implementarmos a paginação na busca contemplando também as mensagens locais, pois hoje ela não leva em consideração o AL.

Replying to zapa:

Diogenes,

Vocês já tem isto implementado? Como funciona?

comment:27 Changed 9 years ago by amuller

Havendo divergência, acho que cada empresa deve dar seu voto, e a maioria que decida. Como eu não tenho direito a voto, espero que alguém se manifeste.

comment:28 Changed 9 years ago by niltonneto

Muller, Se houver alguma interferência no comportamento atual da pesquisa nas pastas IMAP, acho que vocẽ é mais indicado para ajudar na decisão. Caso contrário, a Celepar se abstém da votação, uma vez que não utiliza (ainda) nem implementa o arquivamento local.

comment:29 Changed 9 years ago by diogenesduarte

Acho que o que não pode é ter paginação e não contemplar mensagens locais, que é como está atualmente. Se for fazer a paginação, acho que caberia a quem for implementar, após essa discussão, escolher um caminho e dizer qual. Caso a maioria decida que não é viável implementar, acho que a única opção seria voltar a revisão e deixarmos a busca sem a paginação, pelo menos até segunda ordem.

comment:30 Changed 9 years ago by zapa

Nenhuma implementação poderia inviabilizar alguma feature já existente. Houve interferência na funcionalidade.

Concordo com o DDuarte, entre paginar e não ter a inclusão das msg locais, a preferência seria não paginar e inclui-las, alias como tínhamos em produção.

Como parece que somente a Prodeb e Serpro utilizam, e é requisito fundamental destes, caso não afete outras funcionalidades concordo com a reversão.

comment:31 Changed 9 years ago by zapa

Necessitamos definição é fator crítico da versão. Quem é o responsável por reverter?

comment:32 follow-up: ↓ 33 Changed 9 years ago by zapa

Creio ter ficado decidido. Mário tens como reaplicar o código?

comment:33 in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 9 years ago by brunocosta

  • Status changed from new to closed
  • Resolution set to fixed

Resolvido na revisão [3380]

O código referente ao ticket #428 foi retirado para restabelecer a funcionalidade de busca no arquivamento local baseado no código do expresso 2.1.

Replying to zapa:

Creio ter ficado decidido. Mário tens como reaplicar o código?

comment:34 in reply to: ↑ 33 ; follow-ups: ↓ 35 ↓ 36 Changed 9 years ago by amuller

Replying to brunocosta:

Resolvido na revisão [3380]

Bruno: Esteja ciente que esta revisão desfaz um monte de correções de problemas da busca.

Por exemplo aquela serialização que usava "--" como delimitador que era muito problemática. Basta ter um email com "--" em algum campo que para de funcionar.

Tem outros problemas também, mas estes eu deixo para seus usuário te relatarem.

comment:35 in reply to: ↑ 34 ; follow-up: ↓ 37 Changed 9 years ago by brunocosta

Replying to amuller:

O problema é que isso tudo foi implementado sem que busca no arquivamento local funcionasse, o que tem que acontecer é que isso seja aplicado de novo considerando a busca do arquivamento local.

Alguns eu até já vi aqui comparando os código, e eu concordo inteiramente com você em retirar essa serialização fora do padrão. Se você me passar os tickets envolvidos nos podemos ver o que pode ser feito.

Replying to brunocosta:

Resolvido na revisão [3380]

Bruno: Esteja ciente que esta revisão desfaz um monte de correções de problemas da busca.

Por exemplo aquela serialização que usava "--" como delimitador que era muito problemática. Basta ter um email com "--" em algum campo que para de funcionar.

Tem outros problemas também, mas estes eu deixo para seus usuário te relatarem.

comment:36 in reply to: ↑ 34 Changed 9 years ago by eduardoalex

AMuller,

Se você sabe, ou tem ideia, dos problemas que foram corrigidos na revisão que foi revertida, por gentileza, crie um ou vários tickets com esses problemas para que sejam resolvidos, pois, diferente do que você disse, não existe os "seus usuários" e sim os "nossos" usuários. E, entre eles, existem pessoas que utilizam a funcionalidade de arquivamento local que foi completamente ignorada quando da implementação to ticket #428

Peço a sua ajuda para que possamos trabalhar em conjunto e fazer o melhor para todos os envolvidos.

Replying to amuller:

Replying to brunocosta:

Resolvido na revisão [3380]

Bruno: Esteja ciente que esta revisão desfaz um monte de correções de problemas da busca.

Por exemplo aquela serialização que usava "--" como delimitador que era muito problemática. Basta ter um email com "--" em algum campo que para de funcionar.

Tem outros problemas também, mas estes eu deixo para seus usuário te relatarem.

comment:37 in reply to: ↑ 35 ; follow-up: ↓ 38 Changed 9 years ago by rodsouza

Replying to brunocosta:

O problema é que isso tudo foi implementado sem que busca no arquivamento local funcionasse, o que tem que acontecer é que isso seja aplicado de novo considerando a busca do arquivamento local.

Se algo não está funcionando reverter para que passe a funcionar é uma decisão que engloba uma série de fatores complexos, como por exemplo todo o trabalho que foi realizado até então. Realizar o procedimento para reverter algo implica em aceitar todo o retrabalho.

Replying to brunocosta:

Alguns eu até já vi aqui comparando os código, e eu concordo inteiramente com você em retirar essa serialização fora do padrão. Se você me passar os tickets envolvidos nos podemos ver o que pode ser feito.

Se algo é revertido então é dever de quem realizou o procedimento observar o que está entre as revisões e reaplicar.

comment:38 in reply to: ↑ 37 Changed 9 years ago by diogenesduarte

Olha só, o ticket #428 era para fazer paginação para pesquisa. Analisando no macro, isso afetou diretamente o arquivamento local pois a busca não o contemplava, inviabilizando uma feature, que como zapa disse e eu concordo, isso é um erro e não deve acontecer. A partir disso foi decidido reverter a revisão, porém, se com isso foram revertidos outras correções, isso aconteceu porque as correções não foram feitas de forma correta. Se existiam problemas além do que o ticket estava descrito, acredito que a forma coerente seria criar um ticket relatando esses problemas, e criar o ticket de paginação, resolver um a um e comitar.

Diante desse problema que ocorreu anteriormente, acredito que o melhor que temos que fazer agora é fazer o que deveria ter sido feito antes... Quem vai corrigir acredito que não seja problema, pois como o conceito aqui é de comunidade, se o problema está lá, alguém vai resolver, só creio que quem os encontrou, deveria informá-los, para que mesmo que ele não possa corrigir, por qualquer que seja o motivo, outro o faça.

Replying to rodsouza:

Replying to brunocosta:

O problema é que isso tudo foi implementado sem que busca no arquivamento local funcionasse, o que tem que acontecer é que isso seja aplicado de novo considerando a busca do arquivamento local.

Se algo não está funcionando reverter para que passe a funcionar é uma decisão que engloba uma série de fatores complexos, como por exemplo todo o trabalho que foi realizado até então. Realizar o procedimento para reverter algo implica em aceitar todo o retrabalho.

Replying to brunocosta:

Alguns eu até já vi aqui comparando os código, e eu concordo inteiramente com você em retirar essa serialização fora do padrão. Se você me passar os tickets envolvidos nos podemos ver o que pode ser feito.

Se algo é revertido então é dever de quem realizou o procedimento observar o que está entre as revisões e reaplicar.

comment:39 Changed 9 years ago by amuller

Eu vou levantar o que precisa ser arrumado, assim que resolver uns problemas do filemanager, e como isso será feito, sem estragar o arquivamento local.

comment:40 Changed 9 years ago by niltonneto

Pessoal, tenham cuidado sempre ao efetuar merges. O número do ticket que corrigiu problema na pesquisa é o #1073.

Note: See TracTickets for help on using tickets.