|
In Grails 2.0.2+, if I define the following domain class:
class Book {
Book parent
static hasMany = [children: Book]
static belongsTo = [parent: Book]
static mapping = {
id generator: "assigned"
}
static constraints = {
parent nullable: true
}
}
and the following unit test:
@TestFor(Book)
class BookTests {
void testCreate() {
Book book = new Book(id: 5)
book.save()
assert book.validate()
assert Book.count() == 1
}
}
The test fails because Book.count() returns 0. If I run this same test in Grails 2.0.1, the test passes. The issue is related to defining id generator: "assigned" AND having hasMany = [children: Book]. If I get rid of the hierarchical relationship or use the default id generator, the test passes. Is this a bug or an intentional behavior change? If the latter, what would the right way to model this case be? Thank you, Steve |
|
It could be related to this bug that I opened:
For me, whenever an object with an assigned key is saved, finder methods (except get()) will not return the instance in the same transaction. Oddly, for me this worked in 2.0.3 and fails in 2.0.4. My ticket didn't have anything to do with mocks, it fails like this for real objects too.
-Aaron On Sat, Jun 16, 2012 at 12:56 AM, sbrudz <[hidden email]> wrote:
|
|
Hi Aaron, Your bug report helped me to find a work-around for this problem:
@TestFor(Book)
class BookTests {
void testCreate() {
Book book = new Book()
book.setId(6)
book.save()
assert book.validate()
assert Book.count() == 1
}
}
The trick was to use setId instead of setting it in the constructor. Thank you! -Steve p.s. I was able to reproduce your bug in my environment. |
|
Glad to be helpful.
Yeah, the "id" property is weird in that it doesn't seem to work when you use it as a map property in the constructor. Very annoying. In general, I don't think Grails is super-friendly towards assigned keys, unfortunately it's a part of life when working on many projects.
On Sat, Jun 16, 2012 at 11:12 AM, sbrudz <[hidden email]> wrote:
|
| Powered by Nabble | Edit this page |
