Transfer deep relationship/order bug
Ok, maybe I'm a bit too geeky, but sometimes I love bugs that take hours of debugging and head scratching to solve. I discovered (and reported to Mark) a simple bug in Transfer.
One of the cooler aspects of being able to design your objects in Transfer is the ability to set a onetomany relationship. You can say that you object is related to N other objects. Transfer then makes it easy to load these objects when you need them. You can even tell Transfer to return the objects as a struct or as an ordered array - and here is where the bug lies. Imagine the following:
You have a Grandparent object.
Grandparents have a onetomany to Kid. You've told Transfer to return the Kids as an array sorted by Age descending.
The Kid object has a onetomany to GrandKid. Since babies are cuter, you've told Transfer to return them sorted by Age ascending.
Ok, now here is where it gets weird, and where I ended up losing a few hours. If you get a Grandparent and then loop over the kids and for each kid, loop over the grandkids, the grandkids will not be sorted correctly. They will sort in the same direction that Kids were sorted.
If you get a Kid however and then get the Grandkids, they will be sorted correctly.
At work, our Admin was doing the Grandparent/Kid/GrandKid thing and our front end was doing the Kid/GrandKid thing. I couldn't understand why the sort kept changing, and since Transfer was caching, the order seemed to be based on whoever ran first.
There is a quick fix for this - and it is incredibly difficult. In my Kid definition, I simply said that the onetomany for Grandkids was lazy. That's it. Once I did that the sorting worked correctly and peace returned to the world at large.
Two final notes: I'm psyched I finally broke Transfer - it means I'm properly learning it! I played with Fusion Reactor on the Mac and was impressed how well it worked there. I did run into an issue with the JDBC wrapper and MySQL. Read this thread for a proper fix.
Comments
His normal answer is; "Write your own query you flaming Galah!!!"
You were quite lucky in this instance.. ;)
This is a Glalah:
http://en.wikipedia.org/wiki/Galah
For years I had no idea what it was, just that a beligirent character from the Aussie soap 'Neighbours' - that we got in the UK when I was a teenager - used it in almost every insult he threw out.. ;)
I think Mark should use it more in response to silly questions on the Transfer list.. lol
If you REALLY loved debugging for hours, I would <em>be glad</em> to let you have a crack at it and I wouldn’t even charge you…
I'm the same way, depending on the situation. If it's code that I wrote, and it's an interesting problem, it's fun. But if it's dealing with a Microsoft product that is misbehaving, like a SQL Server bug, it is NOT fun at all...I think it's because I know that more often than not, there will be no solution for the problem, other than waiting for Microsoft to fix it with an upcoming patch, IF they decide to fix it.
This is only a bug IF and ONLY IF the column names on the Age column has exactly the same name.
If they are different named columns, you'll never have the issue.
This is because Transfer tries to re-use column names, so that queries aren't even wider than they already are.
I've not run in that kind of usecase yet but it's defintely one I will now keep in mind so I can remember to set the child composition as lazy. Has Mark raised this as a bug?