(UFF) JDBC (III) TEPIS II

Transcrição

1 Aula 22: JDBC (III) Diego Passos Universidade Federal Fluminense Técnicas de Projeto e Implementação de Sistemas II Diego Passos (UFF) JDBC (III) TEPIS II 1 / 40

2 Aula Passada Consultas e Atualizações. Manipulação de Resultados. Mapeamento de tipos de dados. ResultSets bidirecionais e auto-atualizáveis. Erros e warnings. Diego Passos (UFF) JDBC (III) TEPIS II 2 / 40

3 Nesta Aula Prepared Statements. Atualizações em lotes. Chaves auto-geradas. BLOBS e CLOBS. Metadados. Transações. Stored Procedures. Escape Sequences. Diego Passos (UFF) JDBC (III) TEPIS II 3 / 40

4 JDBC: Prepared Statements Além dos objetos do tipo Statement, há também os do tipo PreparedStatement. Em última análise, ambos fazem a mesma coisa: executam comandos SQL. No entanto, o PreparedStatement permite que o desenvolvedor pré-compile o SQL. Opção interessante quando o mesmo tipo de comando deve ser executado múltiplas vezes. Permite mudar apenas os parâmetros. Melhora o desempenho, já que o processamento de strings contribui para o overhead do BD. Em certos casos, simplifica o código, já que não é preciso montar strings complexas. De outra forma, o PreparedStatement funciona como um template de comando SQL. Diego Passos (UFF) JDBC (III) TEPIS II 4 / 40

5 JDBC: Prepared Statements (II) A criação de um PreparedStatement é análoga à de um objeto Statement. É feita a partir do objeto Connection. PreparedStatement psmt = con.preparestatement("insert INTO EMPLOYEES (NAME, PHONE) VALUES (?,?)"); Neste exemplo, queremos inserir uma nova entrada na tabela EMPLOYEES. Configuramos os valores para as colunas NAME e PHONE. Mas não estamos, de fato, especificando os valores. Ao invés disso, utilizamos duas vezes o caracter?. Diego Passos (UFF) JDBC (III) TEPIS II 5 / 40

6 JDBC: Prepared Statements (III) Para efetivamente executar um PreparedStatement, precisamos substituir as interrogações por valores reais. Isso é feito através dos métodos setxxx(). Novamente, uma família de métodos para os vários tipos de dados. pstmt.clearparameters(); pstmt.setstring(1, "Jimmy Adelphi"); pstmt.setstring(2, " "); pstmt.executeupdate(); Uma boa prática é apagar valores de execuções anteriores com o método clearparameters(). Nos métodos setxxx(), o primeiro parâmetro indica qual interrogação substituir. Quando todos os parâmetros foram configurados, executamos o comando efetivamente com o método executeupdate(). Diego Passos (UFF) JDBC (III) TEPIS II 6 / 40

7 JDBC: Prepared Statements (IV) Além dos métodos para tipos específicos, há ainda o setobject(). Este método recebe o índice de um parâmetro a ser substituído e um objeto qualquer em Java. O método tenta, então, realizar um mapeamento entre o objeto Java e um tipo compatível SQL. O método tem também versões opcionais com mais parâmetros que permitem ao desenvolvedor especificar como fazer a conversão. Diego Passos (UFF) JDBC (III) TEPIS II 7 / 40

8 JDBC: Prepared Statements (V) Por fim, é possível especificar uma coluna a ser inserida como NULL. Há duas maneiras: Utilizar o comando setnull(). Utilizar o comando setobject() passando o valor null. Note que, em ambos os casos, é necessário especificar o tipo SQL correspondente ao NULL. Integer i = new Integer(32); pstmt.setobject(1, i, Types.INTEGER); pstmt.setobject(2, null, Types.VARCHAR); // Ou pstmt.setnull(2, Types.VARCHAR); Diego Passos (UFF) JDBC (III) TEPIS II 8 / 40

9 JDBC: Atualizações em Lotes Na especificação original do JDBC, a atualização de grandes volumes de dados em uma base não era muito eficiente. Isso porque, para cada atualização, era necessário executar um comando SQL isolado. Mesmo no caso de um PreparedStatement. Para mitigar este problema, foi criado o método addbatch(). Cadastra um comando SQL para ser executado em lotes. Podemos cadastrar vários comandos. Depois de cadastrar os comandos, utilizamos o método executebatch() para executá-los de uma só vez. con.setautocommit(false); Statement stmt = con.createstatement(); stmt.addbatch("insert INTO CUSTOMERS VALUES (1, J Smith, )"); stmt.addbatch("insert INTO CUSTOMERS VALUES (2, A Smith, )"); stmt.addbatch("insert INTO CUSTOMERS VALUES (3, C Smith, )"); stmt.addbatch("insert INTO CUSTOMERS VALUES (4, K Smith, )"); int[] upcounts = stmt.executebatch(); con.commit(); Diego Passos (UFF) JDBC (III) TEPIS II 9 / 40

10 JDBC: Atualizações em Lotes (II) Alguns detalhes sobre o exemplo de código anterior: Na primeira linha, executamos o método setautocommit(false). Como isso, estamos desabilitando o commit automático. Se houver algum erro no meio das inserções, podemos dar um rollback. Visto mais adiante no curso. Os comandos cadastrados com addbatch() são executados na mesma ordem do cadastramento. O método executebatch() retorna um vetor com o número de linhas afetadas por cada comando cadastrado. Embora não seja mostrado no exemplo, é possível remover (todos) os comandos de um batch com o método clearbatch(). Diego Passos (UFF) JDBC (III) TEPIS II 10 / 40

11 JDBC: Atualizações em Lotes (III) Note que só é possível executar comandos SQL que retornam um contador de atualização. Em outras palavras, comandos que fazem atualização. Ao tentar incluir um comando de consulta, a execução retornará uma exceção do tipo SQLException. Outra exceção que pode ser levantada por uma atualização em lotes é a BatchUpdateException. Similar à SQLException, mas contém um vetor com os contadores de atualização das operações que foram realizadas. Diego Passos (UFF) JDBC (III) TEPIS II 11 / 40

12 JDBC: Atualizações em Lotes (IV) Atualizações em lotes também podem ser usadas com PreparedStatement. Para isso, criamos o template do comando e, para cada comando específico, adicionamos uma tarefa ao lote. con.setautocommit(false); PreparedStatement stmt = con.preparedstatement("insert INTO CUSTOMERS VALUES (?,?,?)"); stmt.addint(1,1); stmt.addstring(2,"j Smith"); stmt.addstring(3, " "); stmt.addbatch(); stmt.addint(1,2); stmt.addstring(2,"a Smith"); stmt.addstring(3, " "); stmt.addbatch(); int[] upcounts = stmt.executebatch(); con.commit(); Note que o método addbatch() não recebe argumentos. Ele simplesmente coloca a versão atual do PreparedStatement na fila do lote. Diego Passos (UFF) JDBC (III) TEPIS II 12 / 40

13 JDBC: Chaves Auto-Geradas SGBDs em geral suportam a geração automática de chaves primárias. Tipicamente, um valor inteiro auto-incrementado a cada inserção. A especificação original do JDBC não provia uma maneira de acessar a chave auto-gerada quando de uma inserção. Ao contrário, o desenvolvedor era obrigado a executar um segundo comando, fazendo uma consulta para obter o valor da chave. A partir do JDBC 3.0, esta capacidade foi adicionada. Através da criação de versões alternativas dos métodos execute() e executeupdate(). Permitem receber o argumento Statement.RETURN GENERATED KEYS. Isto sinaliza interesse em obter a chave gerada. Neste caso, após a execução dos métodos, pode-se chamar o método getgeneratedkeys(), que retorna um ResultSet. Diego Passos (UFF) JDBC (III) TEPIS II 13 / 40

14 JDBC: Chaves Auto-Geradas (II) import java.sql.*; public class KeyGenerator { public static void main(string[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver"); Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test"); int newkey = -1; Statement stmt = conn.createstatement(); stmt.executeupdate("insert into people (fullname) values ( John Morgan )", Statement.RETURN_GENERATED_KEYS); ResultSet keys = stmt.getgeneratedkeys(); if (keys.next()) { newkey = keys.getint(1); } keys.close(); System.out.println("New Key: " + newkey); stmt.close(); conn.close(); } } Diego Passos (UFF) JDBC (III) TEPIS II 14 / 40

15 JDBC: BLOBs e CLOBs Sistemas tradicionais baseados em BDs geralmente armazenavam dados pequenos. Nome, CPF, telefone, datas, endereços... De algum tempo para cá, no entanto, tornou-se comum que campos de bases de dados fossem usados para armazenar dados maiores. Textos completos de posts em blogs ou redes sociais. Arquivos binários, como imagens e áudio. Para dar suporte a isso, os SGBDs instituiram os LOBs (Large Objects). Tipicamente, há dois tipos de LOBs: BLOBs: Binary Large Object. CLOBs: Character Large Objects. O SQL99 define ambos os tipos formalmente. Diego Passos (UFF) JDBC (III) TEPIS II 15 / 40

16 JDBC: BLOBs e CLOBs (II) O suporte de fato ao a estes tipos de dados varia de BD para BD. Alguns não suportam. Outros usam nomes não padrão (BINARY, RAW,...). Na versão 1.0 da especificação do JDBC, BLOBs e CLOBs podiam ser acessados apenas através dos métodos getbinarystream() e getasciistream(). Visto anteriormente. A partir da versão 2.0, o JDBC incluiu à interface ResultSet os métodos getblob() e getclob(). A especificação incluiu também classes Blob e Clob, correspondendo aos tipos de retorno dos métodos. Estas classes permitem acesso aos dados através dos métodos getbinarystream() e getasciistream() ou através de leitura direta: getbytes(). getsubstring(). Diego Passos (UFF) JDBC (III) TEPIS II 16 / 40

17 JDBC: Metadados Bancos de dados matém os chamados Metadados. Dados sobre a formato das bases de dados. Logs de operações.... Na maioria das vezes, os metadados são transparentes para as aplicações. Elas conhecem o formato das tabelas. Informação está codificada na aplicação. Algumas vezes, no entanto, a aplicação precisa dinamicamente descobrir a estrutura de uma base de dados. Isto é, precisa ler os metadados. Diego Passos (UFF) JDBC (III) TEPIS II 17 / 40

18 JDBC: Metadados (II) O JDBC provê duas classes para lidar manipulação de metadados: DatabaseMetaData: acesso aos metadados do BD. ResultSetMetaData: acesso aos metadados de um ResultSet. Diego Passos (UFF) JDBC (III) TEPIS II 18 / 40

19 JDBC: DatabaseMetaData Um objeto do tipo DatabaseMetaData é obtido a partir do objeto Connection. Usando o método getmetadata(). Este objeto provê um grande número de métodos que permitem acesso a todo tipo de informação sobre o BD e a base de dados. Alguns exemplos: geturl(): retorna a URL que identifica a base de dados. getmaxconnections(): retorna o número máximo de conexões simultaneas suportadas. gettables(): retorna um ResultSet com todas as tabelas da base de dados. Diego Passos (UFF) JDBC (III) TEPIS II 19 / 40

20 JDBC: ResultSetMetaData Objeto obtido através de um ResultSet resultante de uma consulta. Usando o método getmetadata(). Permite saber: O número de colunas no resultado: getcolumncount(). O nome das colunas: getcolumnlabel(). O tipo de dado de cada coluna: getcolumntypename(). Diego Passos (UFF) JDBC (III) TEPIS II 20 / 40

21 JDBC: ResultSetMetaData (II) import java.sql.*; public class TableViewer { final static String jdbcurl = "jdbc:oracle:customerdb"; final static String jdbcdriver = "oracle.jdbc.driver.oracledriver"; final static String table = "CUSTOMERS"; public static void main(java.lang.string[] args) { System.out.println("--- Table Viewer ---"); try { Class.forName(jdbcDriver); Connection con = DriverManager.getConnection(jdbcURL, "", ""); Statement stmt = con.createstatement( ); ResultSet rs = stmt.executequery("select * FROM "+ table); ResultSetMetaData rsmd = rs.getmetadata( ); int columncount = rsmd.getcolumncount( ); for(int col = 1; col <= columncount; col++) { System.out.print(rsmd.getColumnLabel(col)); System.out.print(" (" + rsmd.getcolumntypename(col)+")"); if(col < columncount) System.out.print(", "); } System.out.println( ); rs.close( ); stmt.close( ); con.close( ); } catch (ClassNotFoundException e) { System.out.println("Unable to load database driver class"); } catch (SQLException e) { System.out.println("SQL Exception: " + e.getmessage( )); } } } Diego Passos (UFF) JDBC (III) TEPIS II 21 / 40

22 JDBC: ResultSetMetaData (III) Exemplo de saída: (Fonte: Java Enterprise in a Nutshell) Diego Passos (UFF) JDBC (III) TEPIS II 22 / 40

23 JDBC: Transações O conceito de transação já foi discutido anteriormente na disciplina. No contexto das EJBs. Uma transação é um conjunto de operações que precisa se comportar de forma atômica. Isto é, como se fosse uma única operação indivisível. No contexto dos Bancos de Dados, transações permitem que múltiplas ações sejam combinadas em uma unidade atômica. Em certas aplicações, uma única operação lógica pode requerer múltiplas alterações na base de dados. Se, por exemplo, um erro ocorre em uma das alterações, queremos poder desfazer todas as alterações que foram efetivamente realizadas. Diego Passos (UFF) JDBC (III) TEPIS II 23 / 40

24 JDBC: Transações (II) Em um Banco de Dados relacional, a execução de uma transação geralmente envolve três passos: Requisitar o início de uma transação. Executar cada uma das operações que compõem a transação. Finalizar a transação (ou com um commit, ou com um rollback). Outro conceito importante relacionado às transações nas bases de dados é o nível de isolamento. As alterações feitas por uma transação podem ter diferentes poĺıticas de visibilidade. No maior nível de isolamento, as alterações feitas em uma transação só ficam visíveis ao resto do sistema após o commit. Em outros casos, pode-se querer um isolamento menor: as alterações ficam visíveis a medida que são realizadas. Diego Passos (UFF) JDBC (III) TEPIS II 24 / 40

25 JDBC: Transações (III) No JDBC, o objeto Connection é responsável pelo gerenciamento de transações. Por padrão, um Connection sempre é criado no modo autocommit. A cada comando SQL executado com sucesso, corresponde um commit automático. Alterações são imediatamente refletidas na base de dados. Vimos anteriormente como desabilitar esse modo: método setautocommit(). É possível verificar o status com o método getautocommit(). Diego Passos (UFF) JDBC (III) TEPIS II 25 / 40

26 JDBC: Transações (IV) Uma vez desabilitado o modo autocommit, o primeiro comando SQL executado implicitamente inicia uma transação. O desenvolvedor é obrigado a, explicitamente, fazer o commit. Método commit() do objeto Connection. try { con.setautocommit(false); stmt.executeupdate("update INVENTORY SET ONHAND = 10 WHERE ID = 5"); stmt.executeupdate("insert INTO SHIPPING (QTY) VALUES (5)"); con.commit(); } catch(sqlexception e) { con.rollback(); } Diego Passos (UFF) JDBC (III) TEPIS II 26 / 40

27 JDBC: Isolamento de Transações O JDBC também suporta diferentes níveis de isolamento para transações. São definidos 5 níveis distintos. O suporte efetivo a cada nível depende do suporte do driver e do BD. Note que o modo padrão também varia de acordo com o driver e o DB. Em geral, níveis mais altos de isolamento resultam em penalidades de desempenho. Diego Passos (UFF) JDBC (III) TEPIS II 27 / 40

28 JDBC: Isolamento de Transações (II) Cada um dos níveis de isolamento é definido por uma constante: TRANSACTION NONE: transações são desabilitadas (ou não suportadas). TRANSACTION READ UNCOMMITED: isolamento mínimo, permite que outras transações vejam dados não comitados. TRANSACTION READ COMMITED: transações não veem dados não comitados. TRANSACTION REPEATABLE READ: leituras têm sempre o mesmo resultado em uma transação. Suponha que uma transação faça uma consulta. Após obter o resultado, outra transação altera (e comita) linhas que estão no resultado. Se a primeira transação repetir a consulta, a resposta será igual à consulta original. Até que ela seja comitada. TRANSACTION SERIALIZABLE: igual ao anterior, mas também vale para inserções. Diego Passos (UFF) JDBC (III) TEPIS II 28 / 40

29 JDBC: Isolamento de Transações (III) O modo de isolamento pode ser configurado através do método settransactionisolation(). Método disponível no objeto Connection. Passando como argumento a constante correspondente ao nível desejado. Mas como saber se um determinado nível está disponível? Ou mesmo, o próprio suporte transacional? Utilizando métodos do objeto DatabaseMetaData: getdefaulttransactionisolation(). supportstransaction(). supportstransactionisolationlevel(). Diego Passos (UFF) JDBC (III) TEPIS II 29 / 40

30 JDBC: Savepoints Algumas vezes, é útil ser capaz de fazer um rollback apenas em parte de uma transação. Por exemplo, dependendo do tipo de erro na transação, queremos deixar algumas das alterações realizadas. Não é exatamente o conceito de transação, mas às vezes é útil. Para dar suporte a este tipo de operação, o JDBC permite que definamos savepoints. Uma marcação em um determinado ponto da transação que podemos referenciar ao fazer um rollback. Neste caso, o rollback é feito somente até o savepoint. Diego Passos (UFF) JDBC (III) TEPIS II 30 / 40

31 JDBC: Savepoints (II) Um savepoint é criado através do método setsavepoint(). Método do objeto Connection. Retorna um objeto do tipo Savepoint. Recebe como argumento uma string: um nome arbitrário para o savepoint. Statement stmt = con.createstatement(); stmt.executeupdate("delete from clients"); stmt.executeupdate("insert into clients (NAME, ID) values ( Charles Babbage, 1)"); Savepoint save = con.setsavepoint("insert_point"); stmt.executeupdate("update clients set NAME = Ada Lovelace where ID = 1"); con.rollback(save); con.commit(); Diego Passos (UFF) JDBC (III) TEPIS II 31 / 40

32 JDBC: Stored Procedures A maioria dos Bancos de Dados relacionais dão suporte às Stored Procedures. Pequenos procedimentos armazenados dentro do próprio BD. Escritos em alguma linguagem interna (e.g., PL/SQL). Permitem uniformizar a execução de tarefas comuns sobre uma dada base de dados. Exemplo: inserção de um novo funcionário gera alterações em várias tabelas. Stored procedure automatiza este processo, encapsulando as várias ações. Também permitem isolar o código da aplicação de eventuais mudanças na estrutura da base de dados. Diego Passos (UFF) JDBC (III) TEPIS II 32 / 40

33 JDBC: Stored Procedures (II) Exemplo (em PL/SQL da Oracle): CREATE OR REPLACE PROCEDURE sp_interest (id IN INTEGER bal IN OUT FLOAT) IS BEGIN SELECT balance INTO bal FROM accounts WHERE account_id = id; bal := bal + bal * 0.03; UPDATE accounts SET balance = bal WHERE account_id = id; END Recebe dois argumentos: id de uma conta e saldo. Atualiza o saldo na tabela. Diego Passos (UFF) JDBC (III) TEPIS II 33 / 40

34 JDBC: Stored Procedures (III) No JDBC, stored procedures são acessíveis pela interface CallableStatement. O CallableStatement é o terceiro e último tipo de statemente disponível no JDBC. Além do Statement e PreparedStatement. Um objeto do tipo CallableStatement pode ser obtido através do objeto Connection. Método preparecall(). Similar ao preparestatement. Diego Passos (UFF) JDBC (III) TEPIS II 34 / 40

35 JDBC: Stored Procedures (IV) O JDBC provê uma sintaxe uniformizada para chamada de storage procedure através da interface CallableStatement. Provê transparência em relação ao BD. Isto é, pode-se trocar de BD sem alterar as chamadas. Há duas variações na sintaxe: Chamadas que não retornam valor. {call procedure name[(?[,?...])]} Chamadas que retornam valor. {? = procedure name[(?[,?...])]} Em ambas, a interrogação serve como um marcador que será substituído por valores dos parâmetros ou variável de retorno. O driver JDBC faz a conversão para a sintaxe esperado pelo BD. Diego Passos (UFF) JDBC (III) TEPIS II 35 / 40

36 JDBC: Stored Procedures (V) Exemplo de uso: CallableStatement cstmt = con.preparecall("{call sp_interest(?,?)}"); cstmt.registeroutparameter(2, Types.FLOAT); cstmt.setint(1, accountid); cstmt.setfloat(2, ); cstmt.execute(); out.println("new Balance: " + cstmt.getfloat(2)); Note que o segundo parâmetro é de entrada e saída. Indicado pelo método registeroutparameter(). Valor resultante obtido pelo método getfloat(). Note ainda os métodos get e set específicos para cada tipo de dados. Finalmente, note que o CallableStatement só é mandatório para storage procedures que retornam valor. Para as outras, podemos usar Statement ou PreparedStatement. Diego Passos (UFF) JDBC (III) TEPIS II 36 / 40

37 JDBC: Escape Sequences BDs diferentes utilizam comandos e/ou caracteres especiais diferentes para realizar certas tarefas. Escape sequences são strings com sintaxe especial que permitem acesso a estes de forma independente do BD. Estas sequencias adotam uma sintaxe padronizada pelo JDBC e são traduzidas pelos drivers para a sintaxe correspondente no BD. Até agora, vimos dois exemplos de escape sequences: Chamada de stored procedures. Formatação de datas e horários. Diego Passos (UFF) JDBC (III) TEPIS II 37 / 40

38 JDBC: Escape Sequences (II) Sintaxe básica: Par de chaves. Palavra-chave. Conjunto (opcional) de parâmetros. Exemplo de palavras-chave já vistas: call, d, t, ts. Outro exemplo de palavra-chave: escape. Define qual é o caracter de escape. stmt.executequery("select * FROM ApiDocs WHERE Field_Name like TRANS\_% {escape \ }"); Diego Passos (UFF) JDBC (III) TEPIS II 38 / 40

39 JDBC: Escape Sequences (III) Outra palavra-chave é a fn. Permite acesso a funções escalares internas do BD. Exemplo: função SOUNDEX(string). Retorna uma representação numérica do som da string. Exemplo de acesso à função no JDBC: {fn SOUNDEX("Bacon")} Note que a disponibilidade das funções varia de BD para BD. Alguns drivers sequer suportam a escape sequence fn. Diego Passos (UFF) JDBC (III) TEPIS II 39 / 40

40 Referências Conteúdo e exemplos baseados em: Jim Farley e William Crawford. Java Enterprise in a Nutshell: A Practical Guide. Terceira edição. Capítulo 8. Diego Passos (UFF) JDBC (III) TEPIS II 40 / 40