Esse artigo é continuação da primeira parte da minha saga com as tabelas no Azure (http://luticm.blogspot.com/2009/04/troubleshooting-development-storage-e.html)
Depois de analisar muito código e estudar a estrutura do cabeçalho e outras coisinhas relacionadas com o Lite Shared Key, eu saí do computador, respirei um pouco e iniciei outro projeto do zero, onde reconstruí a aplicação, copiando e colando o código do meu artigo de referência.
Depois de tudo montado, fui executar e ... funcionou! Mas que droga, que besteira eu estou fazendo? Code Review, lá vamos nós.
Opa! Eu tinha optado por não herdar minha entidade da classe TableStorageEntity e durante o CTRL+C / CTRL+V eu não levei o campo Timestamp. Será que é isso? Coloquei o campo, usei o DevTableGen, chequei o gerenciamento dos serviços no development storage, executei minha aplicação e ... erro! Mas agora um erro diferente.
Vou poupá-los dos detalhes sórdidos da hora que se seguiu, mas quero alertá-los sobre algumas coisas que eu aprendi, e quem sabe ajudá-los a poupar um pouco de tempo e paciência.
1 – Apesar de não listado neste documento http://msdn.microsoft.com/en-us/library/dd320275.aspx, o Azure na nuvem se vira automaticamente com a coluna timestamp, enquanto é necessário criar a coluna para o ambiente de desenvolvimento local. A documentação do SDK fala sobre a necessidade de existência dos campos, mas não especifica esse detalhe “These system properties are automatically included for every entity in a table. The names of these properties are reserved and cannot be changed. The developer is responsible for inserting and updating the values of PartitionKey and RowKey. The server manages the value of Timestamp, which cannot be modified.”.
O que me fez gastar um tempão foi a mensagem do warning registrado no log, que me colocou na trilha errada.
2 – Recriar a estrutura da tabela e metadados.
Outro detalhe que pode te ajudar durante o desenvolvimento é a configuração da tabela no SQL Server. Veja os passos que eu executei para realizar outros testes:
2.1) Depois que eu deixei o código funcionando, alterei o nome dos campos da entidade de Address e Name para CampoA e CampoB.
2.2) Apaguei o banco de dados no SQL Server e recompilei minha solução, para atualizar a ddl com os novos nomes.
2.3) Executei novamente o comando DevTableGen para gerar o banco de dados e a tabela com os novos campos. Verifiquei no Management Studio, tudo criado corretamente.
2.4) Chequei o status dos serviços no development storage. Todos os serviços rodando e apontando para o local correto (vide figura abaixo). 
2.5) Executei a aplicação e ... Mais um erro!
Muito estranho, o código está atualizado, a estrutura da tabela no SQL Server também já reflete o CampoA, mas porque estou recebendo esse erro?
Depois de analisar um pouco o que estava acontecendo, supus a causa raiz. O problema está com os metadados armazenados pelo serviço do development storage, que os manteve em cache e mostra corretamente o status de running, pois o banco de dados e a tabela existem, mas sem nenhum refresh do esquema.
Quando tentamos recuperar a propriedade CampoA, o serviço não consegue fazer o mapeamento com os seus metadados e retorna um erro, mesmo com a estrutura correta criada no banco de dados. Um simples restart do serviço de tabela trás os novos metadados e deixa a aplicação funcionando corretamente.
Então fica a dica: quando estiver desenvolvendo em seu ambiente local, depois de usar o DevTableGen, não esqueça de reiniciar o serviço de armazenamento das tabelas, para que os metadados sejam atualizados.
Depois que os problemas estão resolvidos você olha para trás e pensa: putz, quanta besteira, eu devia ter conseguido resolver isso em 10 minutos. Mas desenvolvimento é assim, ainda mais quando estamos com CTPs.
Espero que esse post ajude algum desenvolvedor desamparado. :-)
Até o próximo post.
[]s
Luciano Caixeta Moreira
luticm79@hotmail.com
luciano.moreira@srnimbus.com.br
Nenhum comentário:
Postar um comentário