Oi pessoal.
Hoje eu vi em uma apostila de hibernate a seguinte pergunta : Por que utilizamos o Long e não o long para o campo id ?
Essa pergunta estava abaixo de uma classe que foi mapeada para uma tabela. O atributio id estava como private Long id;
Eu pensei que Long e long desse na mesma não é?
Acho que é por causa que Long por ser uma classe aceita valores null por exemplo
[code]Long i = null; //é válido
long i = null; //inválido vai dar erro[/code]
Long é um objeto igual a String, Boolean, Integer
long é um tipo primitivo igual a int, boolean e etc
Como o Ivan disse … Se na sua base de dados a coluna mapeada para o id pode conter valores nulos, então o mapeamento deve ser feito para Objeto não para os tipos primitivos, se não acabará recebendo um erro …
[]'s
Oi!
Long é um Wrapper (Objeto), enquanto long é um tipo primitivo, como já foi dito.
Só estou postando aqui, porque eu sempre usei e vi usar o ID de uma tabela como chave primária.
Sendo assim, dizer que uma chave primária é “Nula”, é no minimo estranho!
Eu entendo que quando geramos um registro geramos uma chave primária, já pensou gerar um registro cuja chave primária é nula?
Portanto, eu sempre dei valores primitivos ao ID, long, porque possui 64 bits.
Bom, está dada a opinião.
Abraços.
[quote=nel]Oi!
Long é um Wrapper (Objeto), enquanto long é um tipo primitivo, como já foi dito.
Só estou postando aqui, porque eu sempre usei e vi usar o ID de uma tabela como chave primária.
Sendo assim, dizer que uma chave primária é “Nula”, é no minimo estranho!
Eu entendo que quando geramos um registro geramos uma chave primária, já pensou gerar um registro cuja chave primária é nula?
Portanto, eu sempre dei valores primitivos ao ID, long, porque possui 64 bits.
Bom, está dada a opinião.
Abraços.[/quote]
Com certeza.
Quando falei de ID estava falando do atributo … que também geralmente é mapeado para a PK da tabela …
mas o nome do atributo pode referenciar qualquer coluna … mesmo sendo estranho … enfim …
Mas a idéia é para qualquer coluna/atributo, não necessáriamente o id/PK …
Desculpe, acho que me expressei mal … A ideia é que uma coluna da tabela que aceite valores nulos, deve ser mapeada para um Wrapper …
[]'s
Ja se perguntou porque String é com “S” e nao “s”??
Talvez porque as Strings do java, sejam um vetor de Chars… esse é minha tese. Toda variavel… respeita a regra de ser minusculo.
Ex: nomeDaVariavel
porque String é uma classe e classes iniciam seu nome com letra maiuscula por padrão.
Abraço
Por padrão no Hibernate eu sempreusei tipo Wrapper, principalmente por causa da possibilidade do uso de null e tambem de recusos que os tipos dão como parses, opção de ver a instancia essa coisas.
Agora se há uma convenção no mapeamento de classes de entidade no Hibernate, realmente nunca me apeguei a esse detalhe. Será que alguem ja viu ?
Alias que interessante, na apostila da Caellum do curso -fj28, pagina 16 é sugerida essa discussão
a Pergunta é por que utilizamos o Long e não o long para o campo id. (So que neste caso este questionamento é referente aocodigo abaixo)
@Entity
public class Produto {
@Id @GeneratedValue
private Long id;
private String nome;
private String descricao;
private Double preco;
// getter e setters
}o Long pode receber um null (:
[quote=nel]Oi!
Long é um Wrapper (Objeto), enquanto long é um tipo primitivo, como já foi dito.
Só estou postando aqui, porque eu sempre usei e vi usar o ID de uma tabela como chave primária.
Sendo assim, dizer que uma chave primária é “Nula”, é no minimo estranho!
Eu entendo que quando geramos um registro geramos uma chave primária, já pensou gerar um registro cuja chave primária é nula?
Portanto, eu sempre dei valores primitivos ao ID, long, porque possui 64 bits.
Bom, está dada a opinião.
Abraços.[/quote]
Se a chave for gerada automaticamente no banco (por meio de uma sequência por exemplo) haverá um momento onde o id da entidade é nulo. Quando você cria a entidade, mas ainda não a persistiu. Por isso o uso de Long e não de long num atributo que será mapeado para pk.
Falou.
[quote=wagnerfrancisco][quote=nel]Oi!
Long é um Wrapper (Objeto), enquanto long é um tipo primitivo, como já foi dito.
Só estou postando aqui, porque eu sempre usei e vi usar o ID de uma tabela como chave primária.
Sendo assim, dizer que uma chave primária é “Nula”, é no minimo estranho!
Eu entendo que quando geramos um registro geramos uma chave primária, já pensou gerar um registro cuja chave primária é nula?
Portanto, eu sempre dei valores primitivos ao ID, long, porque possui 64 bits.
Bom, está dada a opinião.
Abraços.[/quote]
Se a chave for gerada automaticamente no banco (por meio de uma sequência por exemplo) haverá um momento onde o id da entidade é nulo. Quando você cria a entidade, mas ainda não a persistiu. Por isso o uso de Long e não de long num atributo que será mapeado para pk.
Falou.[/quote]
De qualquer forma o valor não foi persistido em banco, portanto, se é nulo ou 0, não faz diferença para esse caso.
Em particular, a maioria das database tem uma PK gerada automaticamente, o que evitaria um nulo. Só me refiro que o long evitaria uma falha do banco, por exemplo, em por algum motivo persistir um nulo como PK, onde seria persistido um 0.
Apenas isso.
[quote=nel][quote=wagnerfrancisco][quote=nel]Oi!
Long é um Wrapper (Objeto), enquanto long é um tipo primitivo, como já foi dito.
Só estou postando aqui, porque eu sempre usei e vi usar o ID de uma tabela como chave primária.
Sendo assim, dizer que uma chave primária é “Nula”, é no minimo estranho!
Eu entendo que quando geramos um registro geramos uma chave primária, já pensou gerar um registro cuja chave primária é nula?
Portanto, eu sempre dei valores primitivos ao ID, long, porque possui 64 bits.
Bom, está dada a opinião.
Abraços.[/quote]
Se a chave for gerada automaticamente no banco (por meio de uma sequência por exemplo) haverá um momento onde o id da entidade é nulo. Quando você cria a entidade, mas ainda não a persistiu. Por isso o uso de Long e não de long num atributo que será mapeado para pk.
Falou.[/quote]
De qualquer forma o valor não foi persistido em banco, portanto, se é nulo ou 0, não faz diferença para esse caso.
Em particular, a maioria das database tem uma PK gerada automaticamente, o que evitaria um nulo. Só me refiro que o long evitaria uma falha do banco, por exemplo, em por algum motivo persistir um nulo como PK, onde seria persistido um 0.
Apenas isso.[/quote]
Eu acho que faz diferença sim. Se você executar uma operaçao saveOrUpdate ou merge e a entidade estiver com o id igual a zero ao invés de nulo, eu acredito que o Hibernate vai tentar fazer um update na entidade mesmo quando você acabou de criá-la, já que ele vai usar o Id pra saber qual operaçao realizar (salvar ou atualizar).
Se você estiver usando um wrapper no id e ele for nulo, o Hibernate vai entender que deve executar uma operaçao de Insert e o banco se encarregará de fornecer um novo valor para o id, não vejo problema com possíveis falhas no banco nesse caso.
E ainda deve-se ressaltar que 0 pode ser um id válido no teu banco.
Abraço.
De qualquer forma vejo que é bem possível que tenha de haver um tratamento no método de persistência.
Você pode passar um ID nulo quando na realidade estava querendo atualizar a entidade e não inserir, sendo que o mesmo é verdade para um ID 0.
Mas sem problemas, eu apenas não gosto de pensar na possibilidade de haver uma inserção de um valor nulo na database, mesmo que o 0 possa vir a ser um ID válido. Se for o caso, há algo de errado na implementação.
Abraços.
[quote=nel]De qualquer forma vejo que é bem possível que tenha de haver um tratamento no método de persistência.
Você pode passar um ID nulo quando na realidade estava querendo atualizar a entidade e não inserir, sendo que o mesmo é verdade para um ID 0.
Mas sem problemas, eu apenas não gosto de pensar na possibilidade de haver uma inserção de um valor nulo na database, mesmo que o 0 possa vir a ser um ID válido. Se for o caso, há algo de errado na implementação.
Abraços.[/quote]
Oi nel. Eu entendo sua preocupação, mas o Hibernate já resolve isso. Se for nulo, ele insere, se não for, atualiza (quando a chave é gerada automaticamente). Se você mandar uma entidade com id nulo ser atualizada, algo está errado na implementação, afinal, com Hibernate isso não deveria acontecer.
Abraço.