Para dados persistentes, em Terracota, de como evoluir aulas?

Question

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.

1. 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).
2. Fazer Terracota DSO e o Toolkit API diferentes em suas reações para evoluíram definições de classe?
3. 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?
4. 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)?

Answer 1

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:

1. 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.
2. Código da aplicação deve ter a "antiga/nova versão de" suporte bem.
3. Ter uma instância que continuaria a trabalhar com a versão antiga, até dados expira/obsoleto (baseado em um antigo nome da cache)
4. 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.