make_unsaved called in make_unsaved flips the nerfed flag and saves the blueprint

[fosrias]

Am I missing something.

Inside my primary blueprint, I am creating associations for a related
class in a helper mixin and making that related class for a foreign
key. The associations required in that related class are built using
make_unsaved in the helper so that I then make the class from this
secondary blueprint and get its id for my foreign key.

When I then use make_unsaved to build the primary blueprint, the
nerfed flag is reset by the other make_unsaved calls in building the
related class inside it. Thus, the make_unsaved call passes the unless
Machist.nerfed? test and tries to save the blueprint I don't want
saved.

Thus, my make_unsaved is saved if there are any calls to make_unsaved
in the body of the blueprint. This seems non-intuitive.

Any ideas how to prevent this non-intuitive breakdown or work arounds?
At present, I am going to add my own 'make_unsavable' method to
machinist that saves the nerfed state of machinist. Would rather use
the base functionality, but can't see a way to do that.

Thanks.

[fosrias]

Having looked a little deeper, seems a patch is needed to keep this
intuitive.
The following fixes the problem:

def self.with_save_nerfed
previous_nerfed = @@nerfed
begin
@@nerfed = true
yield
ensure
@@nerfed = previous_nerfed
end
end

By tracking the previous nerfed value, internal calls do not reset the
value, but restore it to what it was when the internal call is made.
Thus, if Machinist was already nerfed based on a top-level
make_unsaved call, it will remain nerfed.

[Pete Yandell]

You're calling make_unsaved inside a blueprint? That's crazy talk!

It does kinda make sense that you should be able to do that though.

Feel like writing a test for your patch, and sending me a pull request
on github?

- Pete

[Mark W. Foster]

If that is crazy, then you really will think my make_saved override to force
a save no matter what is crazy. However, it really works well for testing
dependent models independently using blueprints.

In any case, glad to submit a patch on the make_unsaved. Do you have a
github site that contains your test setup that I could use existing models
for the test? Or, what do you need for the test? A generic blueprint
definition and an associated test and you will fill in the blanks or what?

Mark

- Pete

--
You received this message because you are subscribed to the Google Groups
"Machinist Users" group.
To post to this group, send email to machini...@googlegroups.com.
To unsubscribe from this group, send email to
machinist-use...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/machinist-users?hl=en.

[Pete Yandell]

On 26 March 2010 05:46, Mark W. Foster <foste...@gmail.com> wrote:
> In any case, glad to submit a patch on the make_unsaved. Do you have a
> github site that contains your test setup that I could use existing models
> for the test? Or, what do you need for the test? A generic blueprint
> definition and an associated test and you will fill in the blanks or what?

Machinist lives on github here: http://github.com/notahat/machinist

Fork away!

- Pete

[Mark W. Foster]

Hi Pete:

Pull request sent. Let me know if you have any questions.

Also, would you be willing to add a method:

make_forced

to machinist. It forces a blueprint to be made inside a nerfed blueprint. I
am sure you think this is crazy as you did the above, but I find it useful
for creating standalone blueprints where the existence of saved association
is needed and I need to access its id inside another blueprint.

If so, I will send you a pull request with a test.

Machinist is cool.

Mark

-----Original Message-----
From: machini...@googlegroups.com
[mailto:machini...@googlegroups.com] On Behalf Of Pete Yandell
Sent: Friday, March 26, 2010 5:38 PM
To: machini...@googlegroups.com
Subject: Re: [machinist-users] Re: make_unsaved called in make_unsaved flips
the nerfed flag and saves the blueprint

Fork away!

- Pete

--