Problem with relationships on legacy db
Reported by Justin Smestad | December 9th, 2008 @ 01:30 PM
If you run this code, it will say that .content does not exist. This is being run on a vBulletin database. This same data works in AR, so it must be something with DM and legacy keys. dkubb told me to submit this 'generic' ticket. This is using DM 0.9.8. All the data is being loaded into an object but the accessors to output the data does not work.
Comments and changes to this ticket
-
Dan Kubb (dkubb) February 21st, 2009 @ 01:16 AM
- Tag changed from “legacy, models, mysql” to “dm-core, legacy, models, mysql”
- State changed from “unconfirmed” to “hold”
Justin, is this still a problem for you?
FYI: We'll need the schema in order to reproduce this error. It would also be helpful to reduce the test case into something smaller, since running a sinatra app -- even one as simple as this -- is not really the ideal environment to debug this problem in.
Upon looking at the model though, I can say that the :child_key should map to an actual property in the model. Other than the :field definition, everything should refer to the actual properties used and not the underlying columns. I don't know if this is your problem, but it is something to consider.
Marking this as on-hold until Justin replies with further information.
-
-
Dan Kubb (dkubb) July 19th, 2009 @ 04:18 PM
- State changed from “hold” to “not-applicable”
@Justin: The new dm-core 0.10 has a ton of specs for compound keys, as well as aliased keys like this, so I am going to mark this as resolved. Please try 0.10 (edge) dm-core and if it doesn't resolve your issue add a comment, I'll open this back up and we can start to debug it.
What I would suggest, to make debugging go more swiftly and to have this ticket bumped up higher in priority, is a standalone script that reproduces the problem on any machine. In this case we would need to translate the schema provided in HTML format into a database (probably inaccurately), and then load it up with test data, and then run the script. Not to mention that this would take an hour or more to setup, if there was a tiny difference anywhere in the process it wouldn't allow a proper reproduction of the bug.
A standalone script with a test case reduction is far more useful because we can run it locally, without any outside dependencies, and reproduce the problem quickly. (By reduction I mean that all the extra details are removed and only the details relevant to the problem remain.)
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Dan Kubb (dkubb)
Justin Smestad