Is there a replacement for update_attribute? I know you can still use it in Rails 3 but you get deprecation messages.
The reason why I need to use update_attribute is because I need to skip validations but run callbacks.
The only way that I've found of doing this (and avoid deprecation messages), is by simply extracting the code from update_attribute:
Object.send("#{attribute}=", value)
Object.save(:validate => false)
I'd like to know if there is another (proper) way of doing this.
Thanks.
I would suggest what the answer is no.
You cannot pass false to update_attributes to skip validation.
I would recommend you update_column, but this method skip callbacks. And judging by you question it isn't what you need.
Update:
I've found interesting table in that presentation. That I guess can prove my opinion.
Judging by this table there is only one method which satisfies the conditions.
Would you consider using conditional validation? http://guides.rubyonrails.org/active_record_validations_callbacks.html#conditional-validation
You could set an attribute on the object to disable the validation in question for the current record.
From the validations documentation:
The validation process on save can be skipped by passing :validate => false. The regular #save method is replaced with this when the validations module is mixed in, which it is by default.
So simply set your attribute to the correct value and call save with the validates parameter set to false. You do not need to use send, either, unless you have code that relies on metaprogramming, but that is not obvious from your example.
object.attribute = value
object.save(:validate => false)
Related
I'm not sure if this is a bug or not, so I'm asking here, rather than submitting a bug report.
In the documentation for the latest version of hapijs (16.1.1)
https://hapijs.com/api#serverlookupid
For server.lookup, it clearly indicates that an 'id' property can be a string.
const route = server.lookup('root');
However strings are expressively forbidden by the actual implementation code.
https://github.com/hapijs/hapi/blob/master/lib/connection.js#L340
Hoek.assert(id && typeof id === 'string', 'Invalid route id:', id);
Am I missing something here? Is this a bug, or an error in the documentation, or am I simply misunderstanding something?
It seems an strange limitation to impose. Strings are a lot more logical for a route id.
The other issue, is that in the index.d.ts, it specifically forces the use of a string parameter.
This functionality just seems completely broken. How am I supposed to use it, if when creating a route I need to use a numeric id, and then when trying to retrieve it I'm forced to use a string?
You are reading the assert backwards. The error message only displays if the assertion fails. If an id is provided it can only be of type string.
The title pretty much sums it up, but here's the long version anyway.
After posting a small snippet of perl code, I was told to avoid indirect object notation, "as it has several side effects". The comment referenced this particular line:
my $some_object = new Some::Module(FIELD => 'value');
As this is how I've always done it, in an effort to get with the times I therefore ask:
What's so bad about it? (specifically)
What are the potential (presumably negative) side effects?
How should that line be rewritten?
I was about to ask the commenter, but to me this is worthy of its own post.
The main problem is that it's ambiguous. Does
my $some_object = new Some::Module(FIELD => 'value');
mean to call the new method in the Some::Module package, or does it mean to call the new function in the current package with the result of calling the Module function in the Some package with the given parameters?
i.e, it could be parsed as:
# method call
my $some_object = Some::Module->new(FIELD => 'value');
# or function call
my $some_object = new(Some::Module(FIELD => 'value'));
The alternative is to use the explicit method call notation Some::Module->new(...).
Normally, the parser guesses correctly, but the best practice is to avoid the ambiguity.
What's so bad about it?
The problems with Indirect Method Notation are avoidable, but it's far easier to tell people to avoid Indirect Method Notation.
The main problem it's very easy to call the wrong function by accident. Take the following code, for example:
package Widget;
sub new { ... }
sub foo { ... }
sub bar { ... }
sub method {
...;
my $o = new SubWidget;
...;
}
1;
In that code, new SubWidget is expected to mean
SubWidget->new()
Instead, it actually means
new("SubWidget")
That said, using strict will catch most of these instances of this error. Were use strict; to be added to the above snippet, the following error would be produced:
Bareword "SubWidget" not allowed while "strict subs" in use at Widget.pm line 11.
That said, there are cases where using strict would not catch the error. They primarily involve the use of parens around the arguments of the method call (e.g. new SubWidget($x)).
So that means
Using Indirect Object Notation without parens can result in odd error messages.
Using Indirect Object Notation with parens can result in the wrong code being called.
The former is bearable, and the latter is avoidable. But rather than telling people "avoid using parens around the arguments of method calls using Indirect Method Notation", we simply tell people "avoid using Indirect Method Notation". It's just too fragile.
There's another issue. It's not just using Indirect Object Notation that's a problem, it's supporting it in Perl. The existence of the feature causes multiple problems. Primarily,
It causes some syntax errors to result in very odd/misleading error messages because the code appeared to be using ION when it wasn't.
It prevents useful features from being implemented since they clash with valid ION syntax.
On the plus side, using no indirect; helps the first problem.
How should that line be rewritten?
The correct way to write the method call is the following:
my $some_object = Some::Module->new(FIELD => 'value');
That said, even this syntax is ambiguous. It will first check if a function named Some::Module exists. But that's so very unlikely that very few people protect themselves from such problems. If you wanted to protect yourself, you could use the following:
my $some_object = Some::Module::->new(FIELD => 'value');
As to how to avoid it: There's a CPAN module that forbids the notation, acting like a pragma module:
no indirect;
http://metacpan.org/pod/indirect
The commenter just wanted to see Some::Module->new(FIELD => 'value'); as the constructor.
Perl can use indirect object syntax for other bare words that look like they might be methods, but nowadays the perlobj documentation suggests not to use it.
The general problem with it is that code written this way is ambiguous and exercises Perl's parser to test the namespace to e.g. check when you write method Namespace whether Namespace::method exists.
I have a simple MSpec test in which I am passing a null value into a method parameter (of type string) in a Because statement. I then check that an exception is thrown in the It statement.
Because _of = () => _exception = Catch.Exception(() => foo(null));
It should_throw_an_exception = () =>_exception.ShouldBeOfType<Exception>();
I need another test when the parameter is an empty string and the assertion should stay the same. I could write another test, duplicating code.
Or, is there a neater way to do this kind of test in MSpec?
For things like these I would rather use NUnit's TestCaseAttribute to have all combinations of input parameters verified against the same code. MSpec just isn't the best tool for the job here, because it doesn't support test generators like the one mentioned above. Behaviors could help a bit, bit would only de-duplicate the Its. IMHO, there's nothing wrong with mixing test frameworks for things like the one you posted.
Arg<T>.Property is part of the documentation on inline constraints for Rhino Mocks v3.5, but I can't find it in v.3.6. What happened?
The documentation is here: http://ayende.com/Wiki/Rhino+Mocks+3.5.ashx?AspxAutoDetectCookieSupport=1#SimpleConstraints
and Arg<T>.Property is mentioned in the constraints reference table.
This seems to be a bug in the documentation. When examining the Rhino.Mocks.dll (3.6.0.0) in the Object Browser I see that Rhino.Mocks.Arg<T> only offers the methods Is and List but not Property.
However Rhino.Mocks.Constraints contains the Property class. Using the "old" syntax you should be able to do the same:
AAA syntax (producing compile error):
myStub.Expect(x => x.MethodToCall(Arg<T>.Property.Value("PropertyName", myDesiredPropertyValue))).Result(myMockResult);
Old syntax (working):
myStub.Expect(x => x.MethodToCall(null)).Constraints(Property.Value("PropertyName", myDesiredPropertyValue)).Result(myMockResult);
The documentation says "You're probably used to IgnoreArguments(), Constraints() and RefOut(). [...] It is encouraged to use only Arg<T>, it is more consistent and easier to understand, even if sometimes a little more to write."
As Jeff Bridgman noted, you can also use Arg<T>.Matches:
myStub.Expect(x => x.MethodToCall(Arg<T>.Matches(m => m.PropertyName == myDesiredPropertyValue))).Result(myMockResult);
It has the advantage of being 'refactory safe', meaning that you can refactor the name of the property safely without the need to search for any 'magic strings'. It also meets the suggestion in the documentation to rather use Arg<T> instead of Constraints().
I'm curious about whether the following functional test is possible. I'm working with PHPUnit_Extensions_SeleniumTestCase with Selenium-RC here, but the principle (I think) should apply everywhere.
Suppose I execute the following command on a particular div:
function testInput() {
$locator = $this->get_magic_locator(); // for the sake of abstraction
$this->type( $locator, "Beatles" ); // Selenium API call
$this->verifyText( $locator, "Beatles" ); // Selenium API call
}
Conceptually, I feel that this test should work. I'm entering data into a particular field, and I simply want to verify that the text now exists as entered.
However, the results of my test (the verifyText assertion fails) suggest that the content of the $locator element are empty, even after input.
There was 1 failure:
1) test::testInput
Failed asserting that <string:> matches PCRE pattern "/Beatles/".`
Has anyone else tried anything like this? Should it work? Am I making a simple mistake?
You should use verifyValue(locator,texttoverify) rather than verifyText(locator,value) for validating the textbox values
To answer your initial question ("Is it meaningful ..."), well, maybe. What you're testing at that point is the browser's ability to respond to keystrokes, which would be sort of lame. Unless you've got some JavaScript code wired to some of the field's properties, in which case it might be sort of important.
Standard programmer's answer - "It depends".