Para dados persistentes, em Terracota, de como evoluir aulas?
-
10-12-2019 - |
Pergunta
Estamos considerando Terracota para o nosso próximo projeto.Estou intrigado com o seu potencial para fornecer a persistência de dados sem a necessidade por parte de um SGBD.(Ver também Sobre o uso de Terracota como uma solução de persistência)
Uma das principais dores de evolução de software é fazer com que a produção existente de dados de acordo com o novo modelo de dados.Para um RDBMS você gostaria de usar um SQL script de alteração no momento da implantação.Para Terracota feito dados, não é imediatamente claro para mim como lidar com os não-trivial de evolução.
Há um par de parágrafos na Classe Evolução em Terracota documentação mas parece específicos para DSO e permanece bastante superficial.
- Quais são os possíveis maneiras de lidar com o modelo de dados de evolução para o persistente de dados armazenados em Terracota? Estou particularmente interessado na não-DSO cenário (por exemplo,através de Terracota Toolkit API).
- Fazer Terracota DSO e o Toolkit API diferentes em suas reações para evoluíram definições de classe?
- Para compreender as limitações da classe evolução seria uma ajuda para saber como Terracota representa/comunica objeto de dados;há uma especificação para que?
- Talvez haja um esquema de evolução de técnicas de OODBMS mundo que são aplicáveis a Terracota?
Como um exemplo simples, vamos dizer que eu tenho um monte de Car
objetos armazenados e eu mudei o modelYear
campo do Car
classe a partir de uma String
para um int
.De acordo com a documentação que esta não funciona out-of-the-box.Eu posso imaginar uma solução onde o meu antigo Car
é carregado por um separado carregador de classe durante a inicialização do aplicativo e, em seguida, convertido para um novo Car
.Seria uma boa abordagem e por que (não)?
Solução
Depende do seu uso no cenário de caso.
Se o custo de carregamento de seu cache é mínimo (minutos) e você pode pagar para baixo o tempo...então eu vejo nenhum problema de simplesmente reconstruir o cache para uma nova versão.
Se você tem alto custo de preencher seu cache (horas/dias) e você não pode arcar com considerável tempo de inatividade, em seguida, você tem que lidar com novos e velhos versão, ao mesmo tempo, durante o período de transição.Para isso:
- Gostaria de definir um cache separado definição para qualquer nova versão do a classe em cache e deixe versão antiga para expirar em cache.
- Código da aplicação deve ter a "antiga/nova versão de" suporte bem.
- Ter uma instância que continuaria a trabalhar com a versão antiga, até dados expira/obsoleto (baseado em um antigo nome da cache)
- Ter uma instância que lidou com todas as novas solicitações/fluxos com um novo versão (com base em um novo cache de nome)
exemplo:no ehcache.xml você definiria 2 caches (com base no seu exemplo):
<cache name="com.xyz.Car" timeToLiveSeconds="600"/>
<!--New version goes here-->
<cache name="com.xyz.Car2" timeToLiveSeconds="600"/>
No longo prazo, você deve treino convenção de nomenclatura para seus caches que inclui a versão de evolução.