2011-10-07 10 views
6

Sto progettando un sistema in cui i post/discussioni tra utenti possono essere aggiornati per diventare ticket. In un determinato luogo sto cercando di creare una relazione opzionale one-to-one ma sto incontrando alcuni problemi. Di seguito è riportata una versione condensata delle entità sotto i riflettori.Grails/GORM: creazione della relazione opzionale uno-a-uno

Regole:

  1. Un Post può diventare un biglietto, se necessario. (opzionale)
  2. Un biglietto deve avere un post. (Obbligatorio)

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) 
     } 

} 

Questo funziona in una certa misura. Posso:

  1. creare un post lasciando il biglietto attributo null Se e quando il posto viene aggiornato a diventare un biglietto
  2. posso impostare in modo esplicito l'attributo biglietto del Post per puntare al biglietto di genitore.

Tuttavia, questa mappatura non viene applicata a livello di dominio. Lascia spazio per una situazione in cui Ticket1 punta a Post1, ma Post1 punta invece a Ticket2.

Ho provato ad utilizzare un static hasOne = [post: Post] nel biglietteria classe, ma poi appreso che essa impone la presenza di un static belongsTo = [ticket: Ticket] nel Post classe e questo diventa un obbligo rapporto 1 a 1, che non è quello che sto cercando.

C'è un modo per ottenere questa mappatura opzionale 1-a-1 in questo scenario? Qualsiasi suggerimento sarebbe molto utile.

+0

Si prega di chiudere la domanda, se è la risposta alla vostra soddisfazione. Grazie! :-) – sbglasius

+0

Non funziona. Non penso che l'1-1 possa essere creato. Probabilmente dovrei chiuderlo come senza risposta? –

risposta

3

Si potrebbe considerare la possibilità di un validatore personalizzato come

class Post { 
    // Other fields 

    Ticket ticket 

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

Sarebbe questo risolvere il tuo problema?

+0

Ciao, grazie per la soluzione! Funziona (con la piccola modifica apportata) ed è migliore della situazione precedente poiché ora c'è la convalida ad almeno un'estremità. Tuttavia, ora c'è ancora la possibilità di impostare l'argomento del ticket corretto in Post (dal momento che il validatore lo applica), ma poi tornare a Ticket e modificare l'oggetto Post a cui punta. Mi stavo chiedendo se c'è un modo per farla rispettare da entrambe le estremità, ma immagino che non ci sia? :( –

+0

Che ne dici di un'altra convalida nell'altra estremità? Dovrebbe essere possibile? – sbglasius

+0

Provalo ora –