public class main {
public static void main(String[] args) {
Session session = HibernateUtil.getSession();
Query q = session.createQuery("select DISTINCT u FROM Usuario u");
List<Usuario> r = q.list();
String vnome = null;
for (Usuario e: r) {
vnome = e.getNome();
System.out.println("nome"+vnome);
}
}
}
minha entidade:
@Entity
@Table(name="usuario")
public class Usuario {
@Id
@GeneratedValue
private Integer idUsuario;
@Column(name="nomeUsuario")
private String nome;
Meu problema por exemplo o CAMPO ID, é diferente para, entao como o id é um contador no vai funcionar desta forma pois a estrutura da minha tabela esta o seguinte
id nome
1 Eduardo
2 Evandro
3 Evandro
gostaria que apresentasse assim com o distinct:
nome
Eduardo
Evandro
Cara… isso me parece mais um problema de modelagem em si, do que do DISTINCT. DISTINCT DEVE ser evitado ao máximo em qualquer Query.
Se vc tem uma tabela com essas características citadas por vc:
Por exemplo … no seu sistema pode existir dois ‘Evandro’ ?? como vc vai saber quem é quem ? só pelo código ? Ou seja… o seu sistema aceita dois usuários com EXATAMENTE o mesmo nome ?
O que eu quero dizer é que, geralmente não se permite isso. Logo, vc deveria incluir uma clausula de unicidade ( UNIQUE ) no campo nome para que não fosse permitido cadastros do tipo. Até pq, a chave ( ID ) é gerada automaticamente. Por isso está gerando registros não íntegros ( do ponto de vista do BD está, pq a chave muda ( código ) mas do ponto de vista de negócio não ).
logo, vc não deveria era precisar de DISTINCT, pq não deveria permitir esse tipo de registro existir na sua tabela. Se o cara tentar cadastrar um usuário com o mesmo nome de outro, vc tem de barrar essa ação.
sowyer,
Eu não estou vendo problemas com o modelo dele, colocar o nome como chave unica irá fazer com que o sistema não permita usuários
com nomes iguais e isso é muitooooo comum de acontecer, por este motivo os sistemas pedem email, cpf que são valores unicos.
Quanto ao uso do distinct eu digo que é muito comum o uso, principalmente quando se esta fazendo query para relatórios.
Sim sim … entendo. Eu não quis, na verdade, dizer que está errado. Quis dizer que, depende do caso. Se o modelo dele, permitir usuários com o mesmo nome ( ou seja, dois Evendros logados ) e ele vai fazer a distinção dos Evendros por outro campo ( já que não pode ser pelo nome pois o mesmo é igual ). Ele use o outro campo ( o único ) no select.
Só quis alertar que ele pode “poupar” esse trabalho de ter que identificar que Evandro é, por algum outro campo que não seja o nome de cara. Pq DISTINCT além de muito prejudicial a uma query ( Faz, necessariamente, acess full na tabela ), ele aponta ( não quer dizer que é. Claro… há casos que vc vai precisar dele ) um modelo fraco.
Seria o mesmo caso, por exemplo de permitir logins iguais, e ao fazer isso… o forum ter que usar o Email do usuário pra identificar quem, na verdade está logado. Se é o Charles com o Email abc@acb.com ou o Charles com o email bca@bca.com.
Depende muuuuito da aplicação. E em ambas as formas, há uma solução onde vc não precise usar DISTINCT.
Concordo com vc mmaiaco. Eu acho que não fui claro só !
