Boa noite Savius.
O que você precisa fazer, basicamente, é a modelagem via Domain mesmo da sua regra de negócio. Sò assim você vai conseguir identificar ambiguidades, como você citou, e outros possíveis problemas.
Para te ajudar melhor, falo por mim, precisaria compreender um pouco mais da sua necessidade. Mas siga esta regra que citei acima. Não necessariamente uma Domain é um objeto de persistência, o Groovy apenas fornece algumas convenções (CoC) para classes que estão na pasta "domain", como save, update, addTo*, e por aí vai...
Vamos lá...
Um atributo que repete muito em tabelas diferentes e com a mesma finalidade, no processo de normalização de dados você vai se deparar com esta inconsistência. Neste seu caso, o ativo é para saber se a linha é ativa, imagino eu, e a descrição, seja uma breve descrição sobre o valor no banco. São itens necessariamente essenciais, crie uma Domain (X) com estes valores, e nas suas outras Domain, referência ela com o belongsTo (existem outras formas, mas com o mesmo objetivo final de fazer isso, olhe na documentação do GORM sobre relacionamentos). Problema resolvido.
Grande abs e boa sorte com o projeto.
Oi Carlos, obrigado pela atenção. Os campos são exatamente para esta finalidade: identificar a informação para o usuário e "deletar" o resgistro quando necessário. Seguindo sua sugestão seria isso:
class Generica {
String descricao
Boolean ativo
}
e nas demais
class Empregador {
belongsTo [generica : Generica]
}
?
De repente funciona. Aí se eventualmente o Empregador precisar de mais campos não afetaria nenhuma outra que esteja relacionada com a Generica. O pensamento é esse ?
Oi Carlos, também parto da premissa de que estou trabalhando com objetos. E não tenho o menor interesse de trabalhar no lugar do gorm (hehehe)
Fora isso, a idéia de trabalhar com herança não me empolga muito pois sei (experiencia própria) que não é tão simples como geralmente lemos nos livros. Estou mapeando outras classes (pq o sistema já está em produção (tá certo, fui obrigado pelos processos internos a fazer em jsf)) mas agora o sistema está tomando proporções mais administrativas e outros módulos estão previstos. Trabalho com grails desde 2010 e não ousaria compará-lo aqui. Hoje estou com mais autonomia junto a meus gestores para a tomada de decisões. Hoje existe no banco cada tabela (das entidades já citadas) com seus campos string e boolean. O que quero é redesenhar com um melhor design.
Mas fique certo que assim que esta parte estiver "no ponto" venho para postar a solução adotada e ouvir as opiniões.
Abraço.
Apenas para constar, não sou Xiita com tecnologia (a ponto de dizer: seria muito melhor com framework x... se fosse já teria terminado e blá blá...)
Mas quero "qualidade de vida". E apesar de todos os recursos (ou melhor, componentes visuais) que o primefaces oferece, está longe da simplicidade do grails.
Legal Savius.
Entendi a situação. Mas cara boa sorte com o projeto aí.
Grande abs. E qualquer perrengue pode postar por aqui, pois a comunidade está cada dia mais ativa!