-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NULL aasm_state fix (validate => false) #9
Conversation
Thanks for the pull request. But do you mind adding a test? |
:) I would be glad to. But, I'm pretty new to Ruby on Rails tests. I've tested it manually and it seemed to be working propertly. By the way, is it hard to set the aasm_state attribute from the original model on instantiation ? e.g: |
Well, this is what the default (or initial) state is for. It makes sure the state is defined. And nil is not assumed to be a state. There is another issue asking for providing an initial state together with object initialization, like this: u = User.new(aasm_state: 'not-default')
u.state
# => 'not-default' But this is still on my list. |
Regarding your pull request, I'm not really happy to run |
Yeah. I'm also searching for a better solution here! But still, thank you for paying attention to the problem :) |
OK. How about this one ? |
That looks definitely better. But I would like to add some tests before merging it in. But won't find time for it for the next couple of weeks. Maybe you want to give it a try ;) By the way, this is the last open issue for this repo, and it will be the last one. We changed the repo from aasm/aasm to alto/aasm, so that we could transfer the original repo rubyist/aasm over to aasm/aasm. Future issues will be put the again :-) |
Well, according to the Travis-CI system, my modifications didn't pass some of the tests there is. :( I would be very grateful to you, if you'd had these new tests written for me :) Also, I had another proposal for the gem, which I have already implemented in my copy of the gem (it is NOT in repository) - To restrict direct aasm_column attribute assignment (setter that is), because it barely makes any sense, if we have events to transition from one state to another. @user = User.new I think it makes more sense to do it that way |
Indeed, the Travis build is broken. I will fix that when I'm back from my trip in 4 weeks. Do you mind open another issue (on aasm/aasm) with your last proposal? That's an interesting topic, but not easy to change. Maybe others want to participate in that discussion as well. |
OK. Great. I've posted a new issue - aasm#53 ;) |
If you manage to make a new Model instance, e.g User.new, then persisting it with :validate => false option, e.g User.save(:validate => false) would cause it to store "NULL" state, which is not a good thing to come up with.