Executar DDL usando Hibernate

Veja da seguinte otica: o Hibernate é um ORM. Não é para ficar executando comandos SQL, mas mapear um modelo relacional (tabelas) em objetos.

Mantenha isto em Stored Procedure e chame em seu código java.

oyama:

Veja da seguinte otica: o Hibernate é um ORM. Não é para ficar executando comandos SQL, mas mapear um modelo relacional (tabelas) em objetos.

Mantenha isto em Stored Procedure e chame em seu código java.

Blz, mas… Como executar a store procedure dentro do meu DAO usando Hibernate ?? Uso HQL, critéria … o que ? Teria um código de exemplo ?

Valew.

De novo, Hibernate é um ORM. O pattern DAO é Data Access Object. O objetivo de nenhum dos dois é chamar stored procedure (no máximo chamar stored procedure que retorna dados). Portanto isto deveria ser implementado em outra camada do seu sistema.

oyama:

marceloplis:

Blz, mas… Como executar a store procedure dentro do meu DAO usando Hibernate ?? Uso HQL, critéria … o que ? Teria um código de exemplo ?

De novo, Hibernate é um ORM. O pattern DAO é Data Access Object. O objetivo de nenhum dos dois é chamar stored procedure (no máximo chamar stored procedure que retorna dados). Portanto isto deveria ser implementado em outra camada do seu sistema.

Então eu deveria continuar a executar estes tipos de store procedure pelas triggers mesmo ?

Valew.

Isto é uma decisão arquitetural do seu sistema. Com o que você colocou aqui, não dá para decidir nada. Se você for o arquiteto deste sistema, você vai ter que decidir isto.

Dica1: o que esta stored procedure faz é requisito funcional do seu sistema?
Dica2: este sistema pretende ser portável para outro tipo de BD?
Dica3: esta stored procedure esta dentro de algum contexto transacional?

Isto é uma decisão arquitetural do seu sistema. Com o que você colocou aqui, não dá para decidir nada. Se você for o arquiteto deste sistema, você vai ter que decidir isto.

Então, tenho duas store procedures que tenho que executar no sistema, já que por trigger não vai servir.

Sim, ela vai fazer uma ponte de dados entre meu sistema web com o ERP em Delphi, por segurança, não poderei executa-la por trigger e sim no sistema.

Não, é um sistema que complementará um ERP em Delphi que usa o Oracle como banco, por isso, o banco será sempre Oracle.

A execução será após inserir/atualizar dados, por exemplo estruturado assim:

public void armazena(Usuario usuario){
          this.daoFactory.beginTransaction();
          this.daoFactory.getUsuarioDao().atualiza(usuario);
          this.daoFactory.commit();
 
          IF (USUARIO.GETID() == NULL){
               EXECUTAR PROCEDURE INSERE USER
          }ELSE{
               EXECUTAR PROCEDURE ALTERA USER
          }
 
 }

Valew.

marceloplis:

Então, tenho duas store procedures que tenho que executar no sistema, já que por trigger não vai servir.

Crie uma camada de serviço neste sistema de ERP em Oracle+Delphi e acesse estes serviços através da camada de negócio do seu sistema. Se estas funcionalidades que estão na stored procedure pertencem a este ERP, nada mais coerente que eles continuem lá. Defina claramente as responsabilidades de cada sistema. Integrar sistema pensando apenas em dados, vai sempre causar dificuldade de definir fronteiras de sistemas.

oyama:

marceloplis:

Então, tenho duas store procedures que tenho que executar no sistema, já que por trigger não vai servir.

Você que está afirmando isto… O que eu falei que depende de como você quer que seja a arquitetura do seu sistema.

Crie uma camada de serviço neste sistema de ERP em Oracle+Delphi e acesse estes serviços através da camada de negócio do seu sistema. Se estas funcionalidades que estão na stored procedure pertencem a este ERP, nada mais coerente que eles continuem lá. Defina claramente as responsabilidades de cada sistema. Integrar sistema pensando apenas em dados, vai sempre causar dificuldade de definir fronteiras de sistemas.

Veja, são funcionalidades do sistema ERP também, já que nosso objetivo é disponibilizar algumas dessas funcionalidades na WEB. Por isso vou ter algumas funcionalidades funcionando nos 2 sistemas, principalmente nos módulos gerenciais e administrativos.

Valew.

Seguindo conselho do Paulo Silveira, fiz uma conexão via JDBC e executei a procedure e funcionou perfeitamente, só não sei se fiz da maneira certa.

Veja como ficou meu método no meu DAO:

public void procedureAlteraSenha(String username, String senha) throws SQLException, Exception{
		PreparedStatement  	sql = null;
		try{
			cnct.conecta();
			sql = cnct.conn.prepareStatement
			  ("BEGIN " +
			   "	pkg_ps_usuario.Altera_Senha(?,?); " +
			   "END;");
			sql.setString(1, username);
			sql.setString(2, senha);
			sql.executeQuery();
			sql.close();
		}catch (SQLException s) {
			System.out.println(s.getMessage());
			s.printStackTrace();
			throw new java.sql.SQLException(s.getMessage());
		}
		catch (Exception e) {
			System.out.println(e.getMessage());
			throw new Exception(e.getMessage());
		}
		finally {		        
			try{
				if ((cnct.conn!=null) && (!cnct.conn.isClosed())) {
					 cnct.conn.close();
				 }
		     }
		     catch(Exception e){e.printStackTrace();}
	    }
	}

Minha Logic ficou assim:

public void armazena(Usuario usuario) throws SQLException, Exception{
		this.daoFactory.beginTransaction();
		this.daoFactory.getUsuarioDao().atualiza(usuario);
		this.daoFactory.commit();
		//Executa Procedure			
		if(usuario.getId_usuario() == null){
			this.daoFactory.getUsuarioDao().procedureCreateUser(usuario.getUsername(), usuario.getSenha());
		}else{
			this.daoFactory.getUsuarioDao().procedureAlteraSenha(usuario.getUsername(), usuario.getSenha());	
		}
	}

1 - Gostaria de uma opnião sobre o que fiz, foi pura gambiarra ?
2 - Qual a diferença entre PreparedStatement e CallableStatement ? Acima usei PreparedStatement, há algum problema nisso ou teria que usar CallableStatement?

Valew.