:dependent does not work
Reported by vo.x | July 17th, 2008 @ 04:04 PM
Hello,
I have model two models:
class Project
include DataMapper::Resource
property :id, Integer, :serial => true, :key => true
property :name, String, :nullable => false
has n, :features, :dependent => :destroy
end
class Feature
include DataMapper::Resource
property :id, Integer, :serial => true, :key => true
property :project_id, Integer, :nullable => false
property :name, String, :nullable => false
belongs_to :project
end
Unfortunatelly when I tried to use :dependent => :destroy, I only get error ArgumentError: Clause :dependent does not map to a DataMapper::Property
Am I doing something wrong?
Vit
Comments and changes to this ticket
-
Dan Kubb (dkubb) July 17th, 2008 @ 09:09 PM
- State changed from “new” to “open”
- Tag changed from “associations” to “associations, suggestion”
This feature has not been added to dm-core yet.
Last I heard callerche was thinking about starting up work on it, but as far as I know nothing yet has been done on it.
-
-
-
Dirkjan Bussink September 14th, 2008 @ 03:29 PM
That code is hopelessly outdated, someone needs to rewrite this functionality. Please feel free to start working on it!
-
Piotr Nowak November 12th, 2008 @ 04:01 PM
- Tag changed from “associations, suggestion” to “associations, problem, suggestion”
any progress with this issue ?
-
Dan Kubb (dkubb) November 30th, 2008 @ 12:40 PM
- Assigned user cleared.
Just to add a bit more detail to this, we started working on something that would create foreign key constraints/triggers when possible called dm-constraints:
http://github.com/sam/dm-more/co...
There was also some recent discussion on the mailing list about this:
http://groups.google.com/group/d...
If anyone is interested in taking this on, please let me know and I'll assign it to you. For the most part the API for this plugin has been designed, we just need someone to follow through and upgrade dm-constraints to implement it.
-
Dan Kubb (dkubb) December 4th, 2008 @ 02:51 AM
- State changed from “open” to “confirmed”
-
Dan Kubb (dkubb) December 16th, 2008 @ 06:00 PM
- Assigned user set to “Balint Erdi”
Hey Bazz, as you requested, I've assigned this ticket to you.
Please mark it as "accepted" when you decide to work on it so we know it's in-progress.
-
Balint Erdi December 19th, 2008 @ 10:35 AM
A few points I discussed with Dan:
- There are currently no code explicitly defining :dependent options. The current behavior (which should be the default one in the future, too) is :dependent => :protect.
- Tests for the functionality should be in dm-constraints and should adhere to the format of those found in dm-aggregates.
- The tests should be obverseable externally, that is using no mocks.
-
Balint Erdi December 23rd, 2008 @ 05:40 PM
Specs and implementation when dependent is not specified on the association. The behavior is the same as if :dependent => :protect was specified, that is not allowing parent record to be deleted if there are any children.
One error of the implementation is that it checks all associations of the model, not just the one we are dealing with.
What I would like to receive some advice on is how to synchronize changes to dm-core and dm-more. That is relevant since the next step should be to allow :dependent options to be stored in the relation. For that to work, dm-core must be changed which can thus get out-of-sync with dm-constraints (dm-more).
-
Dan Kubb (dkubb) December 24th, 2008 @ 01:55 AM
baaz, you should mark this ticket as accepted if you're working on it.
I would actually suggest that instead of using Relationship#get_children, which is deprecated in dkubb/dm-core, that you use the association accessor on the resource. Not only will this use the cached collection which is useful to prevent unecessary queries, but it will also work in newer versions of dm-core.
What I would suggest at first is monkey patching what you need in dm-core from dm-validations, and then we'll work out a proper API for you to handle extra options in the relationship depending on what you need.
It might also be a good idea to look at the dkubb/dm-core associations and relationship classes. They are quite different from sam/dm-core, but (I hope) more modular and simpler to extend.
-
Balint Erdi December 24th, 2008 @ 02:06 AM
- State changed from “confirmed” to “accepted”
-
Balint Erdi December 24th, 2008 @ 08:29 AM
Thank you, Dan. I guess by when you say "monkey patching what you need in dm-core from dm-validations" you mean "... from dm-constraints". I'll keep working on this, merry christmas!
-
Balint Erdi December 28th, 2008 @ 05:04 PM
Ok, I think I have a working implementation of the above but I am not sure how to proceed. Should I issue a pull request on sam/dm-more (the one I forked from, so that makes more sense) or dkubb/dm-more)?
-
Dan Kubb (dkubb) December 29th, 2008 @ 11:42 AM
baaz sam/dm-more and dkubb/dm-more are in sync at the moment, so you can send me a pull request for sam/dm-more if you want.
-
Balint Erdi January 27th, 2009 @ 04:17 PM
- State changed from “accepted” to “resolved”
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 »
Balint Erdi
Cyril Mougel
Dan Kubb (dkubb)
Dirkjan Bussink
Lin Jen-Shin
maiha
Rick