Long ou long

Acho que é por causa que Long por ser uma classe aceita valores null por exemplo

Long i = null; //é válido

long i = null; //inválido vai dar erro

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.

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.

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 (:

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.

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.

wagnerfrancisco:

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.

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.

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.

nel:

wagnerfrancisco:

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.

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.

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.

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.

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.

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.