2011-10-07 9 views
6

Estoy diseñando un sistema en el que las publicaciones/discusiones entre usuarios pueden actualizarse para convertirse en tickets. En un lugar en particular, estoy tratando de crear una relación opcional uno-a-uno, pero me encuentro con ciertos problemas. A continuación, se presenta una versión condensada de las entidades en el centro de atención.Grails/GORM: creando una relación opcional uno a uno

Reglas:

  1. Un mensaje puede llegar a ser un boleto si es necesario. (opcional)
  2. Un ticket debe tener una publicación. (Obligatorio)

Post.groovy

class Post { 

     String title 
     String description 
     String postedBy 

     Ticket ticket 

     static hasMany = [comments: Comment] 

    static constraints = { 
     title(blank:false) 
     description(blank:false) 
     postedBy(blank:false) 
     ticket (nullable:true,unique:true) 
    } 
} 

Ticket.groovy

class Ticket { 

     String title 
     String description 
     String postedBy 

     Post post 

     static hasMany = [responses: Response] 

     static constraints = { 
       title(blank:false) 
       description(blank:false) 
       postedBy(blank:false) 
       post (nullable:false,unique:true) 
     } 

} 

Esto funciona hasta cierto punto. Puedo:

  1. crear un puesto dejando el billete atributo nulo Si y cuando el puesto se actualiza a convertirse en un billete
  2. puedo establecer explícitamente atributo billete del Post para que apunte a la entrada de los padres.

Sin embargo, esta asignación no se aplica en el nivel de dominio. Deja espacio para una situación en la que Ticket1 apunta a Post1, pero Post1 apunta a Ticket2 en su lugar.

He intentado utilizar un static hasOne = [post: Post] en la clase entradas pero más tarde se enteraron de que en ella se prevén la presencia de un static belongsTo = [ticket: Ticket] en el Post clase y esto se convierte en una relación obligatoria 1-a-1, que no es lo que soy buscando.

¿Hay alguna forma de lograr este mapeo opcional de 1 a 1 en este escenario? Cualquier puntero sería de gran ayuda.

+0

Por favor, cierre la pregunta, si se responde a su satisfacción. ¡Gracias! :-) – sbglasius

+0

No funciona. No creo que se pueda crear 1-1. Probablemente debería cerrarlo como incontestable? –

Respuesta

3

Se podría considerar la posibilidad de un validador personalizado como

class Post { 
    // Other fields 

    Ticket ticket 

    static constraints = { 
    // Other constraints 
    ticket (nullable:true,unique:true, validator: { val, obj -> 
     if(val) { 
     return val.post == obj 
     } 
    }) 
    } 
} 

¿Esto resolver su problema?

+0

Hola, gracias por tu solución! Funciona (con la pequeña edición realizada) y es mejor que la situación anterior, ya que ahora hay validación en al menos un extremo. Sin embargo, ahora todavía hay una posibilidad de que establezca el argumento de ticket correcto en Publicaciones (ya que el validador lo impone) pero luego vuelvo a Ticket y cambio el objeto Post al que apunta. Me preguntaba si hay alguna forma de aplicarlo desde ambos extremos, pero supongo que no? :( –

+0

¿Qué tal otra validación en el otro extremo? ¿Debería ser posible? – sbglasius

+0

Probando eso ahora –

Cuestiones relacionadas