Difference between addTo and simple instantiation on delete rule?

[sergiomichels]

I'm using the Airport - Flight for a delete rule example:

class Airport {
    String name
    static hasMany = [flights: Flight]
}

class Flight {

    String number
    static belongsTo = [airport: Airport]
}
So, if I run the code like the sample in the docs, but adding the flush, the delete of Airport will delete flights.

new Airport(name: "Gatwick")
        .addToFlights(new Flight(number: "BA3430"))
        .addToFlights(new Flight(number: "EZ0938"))
        .save(flush: true)
def airport = Airport.findByName("Gatwick")
airport.delete(flush: true) //this produces the delete of flights.


But if I create airport and flight a little bit different the delete fails:
Airport a = new Airport(name: "Gatwick").save(flush: true)
		
Flight f = new Flight(numberFlight: "BA3430", airport: a).save(flush:true)

assert Airport.count() > 0
assert Flight.count() > 0

def airport = Airport.findByName("Gatwick")
airport.delete(flush: true) //this will not produce the delete of flight

assert Airport.count() == 0
assert Flight.count() == 0
I tested this in an Integration test and in the grails console. And this happens with h2 (dev env) and Oracle (test env) in the console.

Any thoughts why addTo works different?



Thanks,
Sérgio 

[a.shneyderman]

> Airport a = new Airport(name: "Gatwick").save(flush: true)
>
> Flight f = new Flight(numberFlight: "BA3430", airport: a).save(flush:true)

that is why addTo methods were added :-) You are missing

a.flights << f

in this setup.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[burtbeckwith]

Right, but you don't really need that since this is a somewhat contrived example (but typical of integration tests).

It would be rare to create something and delete it in the same session - it'd usually be two separate requests and sessions. When you don't use addTo or manually add the flight to the flights collection, the in-memory state isn't the same as the database state.

To make this more realistic, clear the session to force a re-load from the database (the airport is still cached in the session, so you're just getting the inconsistent instance from before).

Add this line

    Airport.withSession { session -> session.clear() }

before the Airport.findByName call and it will work.

Burt

Alex Shneyderman wrote

> Airport a = new Airport(name: "Gatwick").save(flush: true)
>
> Flight f = new Flight(numberFlight: "BA3430", airport: a).save(flush:true)

that is why addTo methods were added :-) You are missing

a.flights << f

in this setup.

[sergiomichels]

Thanks for the explanation!

Clearing the session works.

Regards,

Sérgio

On Fri, Jul 20, 2012 at 12:20 PM, burtbeckwith <[hidden email]> wrote:

Right, but you don't really need that since this is a somewhat contrived
example (but typical of integration tests).

It would be rare to create something and delete it in the same session -
it'd usually be two separate requests and sessions. When you don't use addTo
or manually add the flight to the flights collection, the in-memory state
isn't the same as the database state.

To make this more realistic, clear the session to force a re-load from the
database (the airport is still cached in the session, so you're just getting
the inconsistent instance from before).

Add this line

    Airport.withSession { session -> session.clear() }

before the Airport.findByName call and it will work.

Burt


Alex Shneyderman wrote

>
>> Airport a = new Airport(name: "Gatwick").save(flush: true)
>>
>> Flight f = new Flight(numberFlight: "BA3430", airport:
>> a).save(flush:true)
>
> that is why addTo methods were added :-) You are missing
>
> a.flights << f
>
> in this setup.
>




--

View this message in context: http://grails.1312388.n4.nabble.com/Difference-between-addTo-and-simple-instantiation-on-delete-rule-tp4631957p4631961.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email