Hibernate: hbm2ddl.auto = update em produção?

Question

Está tudo bem para executar aplicativos Hibernate configurados com hbm2ddl.auto=update para atualizar o esquema de banco de dados em um ambiente de produção?

Answer 1

Não, não é seguro.

Apesar dos melhores esforços da equipe de Hibernate, você simplesmente não pode contar com atualizações automáticas na produção . Escreva seus próprios patches, revê-las com DBA, testá-los, em seguida, aplicá-las manualmente.

Teoricamente, se atualização hbm2ddl trabalhou no desenvolvimento, ele deve trabalhar na produção também. Mas, na realidade, não é sempre o caso.

Mesmo se funcionou OK, pode ser sub-óptima. DBAs são pagos tanto por uma razão.

Answer 2

Nós fazê-lo em produção, embora com uma aplicação que não é missão crítica e sem DBAs bem pagos na equipe. É apenas um processo menos manual que sujeito a erro humano - o aplicativo pode detectar a diferença e fazer a coisa certa, mais você presumivelmente testado em vários ambientes de desenvolvimento e teste.

Uma ressalva - em um ambiente de cluster você pode querer evitá-lo, porque vários aplicativos pode chegar ao mesmo tempo e tentar modificar o esquema que poderia ser ruim. Ou colocar em algum mecanismo onde apenas uma instância é permitido para atualizar o esquema.

Answer 3

criadores

Hibernate desencorajar fazê-lo em um ambiente de produção em seu livro "Java Persistence com hibernar ":

AVISO: Nós vimos usuários do Hibernate tentando usar SchemaUpdate para atualizar o esquema de um banco de dados de produção automaticamente. Isto pode rapidamente acabar em desastre e não será permitido pelo DBA.

Answer 4

Confira XML LiquiBase para manter um changelog de atualizações. Eu nunca tinha usado até este ano, mas eu achei que é muito fácil de aprender e tornar a gestão de controle / migration / mudança de revisão DB muito infalível. I trabalhar em um projeto Groovy / Grails e Grails usa Hibernate embaixo para toda a sua ORM (chamado "GORM"). Usamos Liquibase para gerenciar todas as alterações de esquema SQL, o que fazemos com bastante frequência como nossos evolui de aplicativos com novos recursos.

Basicamente, você mantenha um arquivo XML de changesets que você continue a adicionar como os aplicativos evoluem. Este arquivo é mantido em git (ou o que você está usando) com o resto do seu projeto. Quando seu aplicativo é implantado, cheques Liquibase é mesa changelog no DB você está se conectando por isso vai saber o que já foi aplicada, então é inteligente apenas aplica-se independentemente changesets ainda não foram aplicados a partir do arquivo. Ele funciona absolutamente grande, na prática, e se você usá-lo para todas as suas alterações no esquema, então você pode estar 100% confiante que o código você check-out e implantação será sempre capaz de se conectar a um banco de dados esquema compatível.

A coisa impressionante é que eu posso ter um banco de dados mysql slate totalmente em branco em meu laptop, o fogo até o aplicativo, e de imediato o esquema está configurado para mim. Também torna mais fácil para as alterações do esquema de teste aplicando estes a um local,-dev ou encenar db em primeiro lugar.

A maneira mais fácil de começar com ele provavelmente seria a tomar o seu DB existente e, em seguida, usar Liquibase para gerar um arquivo de Linha de Base inicial. Então no futuro você pode simplesmente anexar a ele e deixe liquibase assumir gerenciar as mudanças de esquema.

http://www.liquibase.org/

Answer 5

O Hibernate tem que colocar o aviso legal sobre não usar atualizações automáticas em prod a cobrir-se quando as pessoas que não sabem o que estão fazendo usá-lo em situações em que não deve ser usado.

Com certeza as situações em que não devem ser usados ??muito mais numerosos aqueles onde é ok.

Eu usei-o durante anos em lotes de projetos diferentes e nunca tive um único problema. Isso não é uma resposta coxo, e não é cowboy codificação. É um fato histórico.

Uma pessoa que diz "não fazê-lo em produção" está pensando em um conjunto específico de implantações de produção, nomeadamente as que ele está familiarizado com (sua empresa, sua indústria, etc).

O universo de "implantações de produção" é vasto e variado.

Um experiente Hibernate desenvolvedor sabe exatamente o DDL vai resultar de uma determinada configuração de mapeamento. Contanto que você testar e validar que o que você espera que termina no DDL (em dev, qa, estadiamento, etc), você está bem.

Quando você está adicionando muitos recursos, atualizações de esquema auto pode ser um poupador de tempo real.

A lista de atualizações material auto não vai alça é interminável, mas alguns exemplos são a migração de dados, adicionando colunas não anuláveis, mudanças de nome da coluna, etc, etc.

Além disso, você precisa tomar cuidado em ambientes em cluster.

Mas, novamente, se você sabia tudo isso, você não estaria fazendo esta pergunta. Hmm . . . OK, se você está fazendo esta pergunta, você deve esperar até que você tenha muita experiência com as atualizações do Hibernate e do esquema auto antes de pensar em usá-lo em prod.

Answer 6

Eu não votar. Hibernate não parecem compreender quando tipos de dados para colunas mudaram. Exemplos (usando MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Existem provavelmente outros exemplos, bem como, tais como empurrando o comprimento de uma coluna da corda por cima 255 e vê-lo converter em texto, MEDIUMTEXT, etc etc.

Com certeza, eu não acho que há realmente uma maneira de "tipos de dados Convert" com sem criar uma nova coluna, copiar os dados e explodindo a coluna idade. Mas no minuto em seu banco de dados tem colunas que não refletem o mapeamento Hibernate atual que você está vivendo muito perigosamente ...

Flyway é uma boa opção para lidar com este problema:

http://flywaydb.org

Answer 7

Como expliquei na este artigo , não é uma boa idéia usar hbm2ddl.auto na produção.

A única maneira de gerenciar o esquema de banco de dados é usar scripts de migração porque:

• os scripts irá residir na VCS ao longo de sua base de código. Quando você check-out um ramo, você recriar todo o esquema a partir do zero.
• os scripts incrementais pode ser testado em um servidor de QA antes de ser aplicado na produção
• não há necessidade de intervenção manual já que os scripts podem ser executados por Flyway , portanto, reduz a possibilidade de humano erro associado com a execução de scripts manualmente.

Mesmo o Hibernate Guia do Usuário aconselhá-lo a evitar o uso da ferramenta hbm2ddl para ambientes de produção.

Answer 8

Eu não arriscar, porque você pode acabar perdendo dados que deveriam ter sido preservadas. hbm2ddl.auto = update é puramente uma maneira fácil de manter seu banco de dados dev até à data.

Answer 9

Nós fazê-lo em um projeto em execução na produção por meses agora e nunca tive um problema até agora. Tenha em mente os 2 ingredientes necessários para esta receita:

1. Projete seu modelo de objeto com uma abordagem de compatibilidade com versões anteriores, isto é deprecate objetos e atributos em vez de remover / alterá-los. Isto significa que se você precisa mudar o nome de um objeto ou atributo, deixar o antigo como é, adicionar o novo e escrever algum tipo de script de migração. Se você precisar alterar uma associação entre objetos, se você já está em produção, isso significa que seu projeto estava errado em primeiro lugar, de modo a tentar pensar em uma nova forma de expressar a nova relação, sem afetar os dados de idade.

2. Sempre Backup o banco de dados antes da implantação.

O meu sentimento é - depois de ler este post - que 90% das pessoas que tomam parte nesta discussão estão horrorizados apenas com o pensamento de usar automações como este em um ambiente de produção. Alguns jogar a bola na DBA. Tome um momento que considerar que nem todos os ambientes de produção irá proporcionar um DBA e não muitas equipes dev é capaz de suportar um (pelo menos para projetos de médio porte). Então, se estamos falando de equipes, onde todos tem que fazer tudo, a bola está sobre eles.

Neste caso, por que não tentar ter o melhor dos dois mundos? Ferramentas como esta estão aqui para dar uma mão amiga, que - com um design cuidadoso e plano - pode ajudar em muitas situações. E acredite em mim, os administradores podem inicialmente ser difícil convencer, mas se eles sabem que a bola não está em suas mãos, eles vão adorar.

Pessoalmente, eu nunca mais voltar a escrever roteiros de mão para estender qualquer tipo de esquema, mas isso é apenas minha opinião. E depois de começar a adotar bancos de dados sem esquema NoSQL recentemente, eu posso ver que mais do que em breve, todas estas operações baseadas em esquema pertencerá ao passado, então é melhor começar a mudar a sua perspectiva e olhar em frente.

Answer 10

• No meu caso (Hibernate 3.5.2, PostgreSQL, Ubuntu), estabelecendo hibernate.hbm2ddl.auto=update novas tabelas única criados e criadas novas colunas em tabelas já existentes.

• Ele fez nem mesas gota, nem colunas gota, nem colunas alter. Ele pode ser chamado uma opção segura, mas algo como hibernate.hbm2ddl.auto=create_tables add_columns seria mais clara.

Answer 11

Não é seguro, não é recomendado, mas é possível.

Eu tenho experiência em um aplicativo usando a opção de atualização automática na produção.

Bem, os principais problemas e riscos encontrados nesta solução são:

• Implementar no banco de dados errado . Se você cometer o erro de executar o servidor de aplicativos com uma versão antiga do aplicativo (EAR / WAR / etc) no banco de dados errado ... Você vai ter um monte de colunas novas, tabelas, chaves estrangeiras e erros. O mesmo problema pode ocorrer com um simples erro no arquivo de fonte de dados, (copiar / colar arquivo e se esqueceu de alterar o banco de dados). Em resumo, a situação pode ser um desastre em seu banco de dados.
• Servidor de aplicativos leva muito tempo para iniciar . Isso ocorre porque o Hibernate tentar encontrar todas criadas tabelas / colunas / etc cada vez que você iniciar o aplicativo. Ele precisa saber o que (quadro, coluna, etc) precisa ser criado. Este problema só piora à medida que as tabelas do banco crescer.
• banco de dados ferramentas é quase impossível para uso . Para criar scripts de banco de dados para ser executado com uma nova versão, você precisa pensar sobre o que vai ser criado pela auto-update depois de iniciar o servidor de aplicativos. Por exemplo, se você precisa preencher uma nova coluna com alguns dados, você precisa iniciar o servidor de aplicativos, espera para Hibernate Creta a nova coluna e executar o script SQL só depois disso. Como você pode ver, ferramentas de migração de banco de dados (como rota migratória, Liquibase, etc) é quase impossível de usar com auto-update habilitado.
• alterações de banco de dados não é centralizado . Com a possibilidade do Hibernate criar as tabelas e tudo o mais, é difícil ver as alterações no banco de dados em cada versão do aplicativo, porque a maioria deles são automaticamente.
• Incentiva lixo no banco de dados . Devido à facilidade de auto-atualização, há uma chance de sua equipe deixar de soltar colunas antigas e mesas antigos.
• desastre iminente . O risco iminente de algum desastre ocorrer na produção (como algumas pessoas mencionados em outras respostas). Mesmo com um aplicativo em execução e atualizável por anos, eu não acho que é seguro. Eu nunca me senti seguro com esta opção.

Então, eu não recomendo a utilização de auto-update em produção.

Se você realmente quiser usar auto-update na produção, eu recomendo:

• redes separadas . O ambiente de teste não pode acessar o ambiente homólogo. Isso ajuda a evitar uma implantação que deveria estar na mudança ambiente de teste o banco de dados de Homologação.
• Gerenciar scripts de fim . Você precisa organizar seus scripts para executar antes de sua implantação (alterar a tabela estrutura, mesa de queda / colunas) e roteiro após a (informação de preenchimento para as novas colunas / tabelas) Implantar.

E, diferente das outras mensagens, eu não acho que a auto-update habilitado que está relacionado com DBAs "muito bem pagos" (como mencionado em outros lugares) ... DBAs tem coisas mais importantes a fazer do que escrever SQL instruções para criar / alterar / excluir tabelas e colunas. Estas tarefas diárias simples pode ser feito e automatizado por desenvolvedores e passado somente para a equipe DBA para revisão, não necessitando de Hibernate e DBAs "muito bem pago" para escrevê-los.

Answer 12

Não, não sempre fazê-lo. Hibernate não lidar com a migração de dados. Sim, ele vai fazer seu olhar esquema corretamente, mas não garante que os dados de produção valioso não é perdida no processo.

Answer 13

• aplicativos normalmente empresariais em grandes organizações executados com privilégios reduzidos.

• nome de usuário de banco de dados pode não ter privilégio DDL para adicionar colunas que hbm2ddl.auto=update requer.

Answer 14

Eu concordo com Vladimir. Os administradores da minha empresa definitivamente não gostaria que eu mesmo a sugerir tal curso.

Além disso, a criação de um script SQL em vez de confiar cegamente Hibernate dá-lhe a oportunidade de remover campos que não estão mais em uso. Hibernate não fazer isso.

E eu acho comparando o esquema de produção com o novo esquema dá-lhe ainda melhor discernimento para wat você mudou no modelo de dados. Você sabe, é claro, porque você fez isso, mas agora você vê todas as mudanças de uma só vez. Mesmo aqueles que fazem você ir como "Que diabos?!".

Existem ferramentas que podem fazer uma delta esquema para você, por isso nem sequer é trabalho duro. E então você sabe exatamente o que vai acontecer.

Answer 15

esquema Applications pode evoluir com o tempo; se você tiver várias instalações, que podem estar em diferentes versões, você deve ter alguma maneira de garantir que a sua aplicação, algum tipo de ferramenta ou script é capaz de migrar esquema e dados de uma versão gradual para qualquer seguinte.

Tendo toda a sua persistência em mapeamentos Hibernate (ou anotações) é uma maneira muito boa para manter a evolução do esquema sob controle.

Você deve considerar que a evolução do esquema tem vários aspectos a serem considerados:

1. evolução do esquema de banco de dados em adicionar mais colunas e tabelas

2. queda de velhas colunas, tabelas e relações

3. enchendo novas colunas com padrões

ferramentas

Hibernate são importantes, em especial no caso (como em minha experiência) você tem diferentes versões do mesmo aplicativo em muitos tipos diferentes de bancos de dados.

O ponto 3 é muito sensível no caso de você estiver usando Hibernate, como no caso de você introduzir um novo boolean propriedade avaliada ou um numérico, se Hibernate vai encontrar qualquer valor nulo em tais colunas, se irá levantar uma exceção.

Então, o que eu faria é: de fato, usar as ferramentas capacidade Hibernate de atualização do esquema, mas você deve adicionar ao lado dele alguns dados e manutenção do esquema de retorno de chamada, como para o preenchimento de defeitos, soltando colunas não são mais usados, e similar. Desta forma, você obter as vantagens (scripts de atualização do esquema independentes de banco de dados e evitar duplicação de codificação das atualizações, em peristence e nos certificados), mas você também cobrir todos os aspectos da operação.

Por exemplo, se uma atualização de versão consiste simplesmente em adicionar um varchar valorizado propriedade (daí coluna), que pode padrão para null, com atualização automática você vai ser feito. Onde mais complexidade é necessário, mais trabalho será necessário.

Isso supõe que a aplicação quando atualizado é capaz de atualizar seu esquema (que pode ser feito), o que também significa que ele deve ter os direitos de usuário a fazê-lo no esquema. Se a política do cliente impede que isso (caso Lizard Cérebro provável), você terá que fornecer o banco de dados -. Scripts específicos