Many-To-Many Relationships not working across multiple repositories
Reported by Matt Savona | June 26th, 2009 @ 08:01 AM
The following code is capable of reproducing the issue:
http://pastie.org/private/rsdhjt2chy2a15ycqfei0a
In this case, two of the models exist in the :default repository, the other exists in :inventory. Various combinations of repository() {} blocks vs. inline :repository => repository() attributes on the associations, changing :child_key to :target_key, etc...all fail with various other exceptions.
If I've defined the associations incorrectly, I apologize. This looks like it should work, but I have had no luck in 0.10 or prior. If there's any other information I can provide, please let me know. Thanks!
Comments and changes to this ticket
-
Dan Kubb (dkubb) June 27th, 2009 @ 04:03 AM
- Assigned user set to “Dan Kubb (dkubb)”
- State changed from “new” to “accepted”
-
Dan Kubb (dkubb) June 30th, 2009 @ 02:21 AM
Attached is a script demonstrating how I would set it up. There is still a problem there, but hopefully this will provide a better example of how to set up cross-repository relationships.
The remaining problem is mostly due to the Query not recognizing that some of the relationships are from different repos, so it constructs a 3 table join to pull back the results, rather than breaking it up when going from Vip -> Interface.
-
Dan Kubb (dkubb) July 16th, 2009 @ 01:03 PM
- Milestone changed from “0.10.0” to “0.10.1”
To be able to perform cross-repository many to many queries we are going to need to have a mechanism that can split up Query objects and perform each at the separate repositories, and feed the results of one into the query for the next.
This will also provide m:m to adapters that do not support joins natively, like the YAML, In-Memory, and basically every non-RDBMS adapter.
It is not likely that this will make it in for the 0.10.0 release, since it will be a rather large undertaking, so I am pushing this out to the next milestone.
-
Dan Kubb (dkubb) October 4th, 2009 @ 09:33 PM
- Milestone changed from “0.10.1” to “0.10.2”
[project:id#20609 not-tagged:"0.10.0" not-tagged:"0.10.1" milestone:id#51895 bulk edit command]
-
Dan Kubb (dkubb) February 1st, 2010 @ 04:33 PM
- Milestone changed from “0.10.2” to “1.0.0”
-
-
-
Dan Kubb (dkubb) February 2nd, 2010 @ 02:47 AM
- State changed from “accepted” to “confirmed”
-
Dan Kubb (dkubb) February 5th, 2010 @ 03:24 AM
- State changed from “confirmed” to “hold”
I can confirm that this behaviour will not be implemented before DM 1.0 is released. Marking this as on-hold.
The only real way to solve this problem would be to rewrite the Query and Adapter APIs from the ground up. The adapters would need to perform as much of the query as they could natively, and then the join would need to happen in memory. This is a non-trivial problem, but I think it is solvable within the next year or two.
I've started work on a side project to address this problem, but it likely won't be going into DM 1.0, and will probably form the base for DM 2.0: http://github.com/dkubb/veritas/
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 »
People watching this ticket
Dan Kubb (dkubb)
Matt Savona
Attachments
Tags
Referenced by
-
1178
Multiple Repository migration and association issues
Some of the cross-repository query issues (like m:m acros...