| Subject: | Fixtures fails to dump related class if class already seen through prior relationship |
Suppose A belongs to B, B might have C, C has many D.
I want to specify a particular A and naturally expect to have all its
related B, C, D dumped as well.
So json config would be:
has_many: {
fetch: '1',
quantity: 'all'
},
might_have: {
fetch: '1'
},
belongs_to: {
fetch: '1'
},
sets: [{
class: 'A',
ids: [ '1' ]
}]
A, B, C get dumped; A is in 'sets' so gets dumped first, then B gets
processed as a relationship of A, then C as a rel of B (since recursive
dump options (_inherited_attributes) include might_have) but not C's
relationships, since 'has_many' is not an inherited attribute. That D
is not automatically dumped is an annoyance, but not the main issue in
this bug report.
(Sidenote: Adding has_many and belongs_to to _inherited_attributes
causes deep recursion - perhaps there is a better way to detect which
objects have already been processed, such as a hash of class name and
primary key, so recursion stops immediately on an already processed
object? Then all types of relationships could be followed, maybe?)
To work around this behaviour, I added 'C' to the sets:
sets: [{
class: 'A',
ids: [ '1' ]
}, {
class: 'C',
ids: [ '7' ]
}]
But still C's relationship D does not get dumped, because C has already
been dumped (the 'exists' file test in dump_object causes the
relationship recursion to be bypassed). That's the bug.
If I just specify C:
sets: [{
class: 'C',
ids: [ '7' ]
}]
then D is dumped as expected. If C was processed first, the result
would be different, but as classes are processed in alphabetical order,
D is never dumped regardless of the ordering in 'sets'. Asymmetrical
behaviour!
The workaround appears to be that a rule must exist for the problem class:
rules: {
C: {
fetch: [{
rel: 'D',
quantity: 'all'
}]
}
}
but that is not obvious (took me several hours to work out) and not
desirable - it would be nice if it just "worked".