I am writting a rake task that would connect to a legacy ORACLE database, get some 'issues' records from a helpdesk application, apply some transformation and store it in another database (Redmine).
The problem is that even though the script runs smoothly on Windows, it fails to run on RHEL 5. The library files are all installed on RHEL 5 and there are no connection errors as such. The script fails on a line '_issue.save' (where _issue is a model of type Issue 0n Redmine)!! There is no error (Just that _issue.save returns false). I've been stuck for the last 2 days on this one.
Any suggestions would be extremely helpful.
I am using Rails 2.1.2, Ruby 1.8.6 (patch level 111) and Rake 0.8.1
Thanks in advance.
No errors, but save returns false means validation might have failed. You can output the validation errors like so:
_issue.errors.each_full { |msg| puts msg }
Here's a bit more info on the each_full method.
I would create some tests and run them on the RHEL server to see where the issue is. I would use RSPEC, but test/unit can get you there as well.
Related
I'm struggling with this for quite a while now: I'm trying to upgrade an app from Rails 3.2 to Rails 4. While on Rails 3.2 all specs are passing, they fail under certain conditions in Rails 4.
Some specs are passing in isolation while failing when run together with other specs.
Example Video
https://www.wingolf.org/ak-internet-files/Spec_Behaviour.mp4 (4 mins)
This example video shows:
Running 3 specs using :focus–––green.
Running them together with another spec–––two specs passing before now fail.
Running the 3 specs, but inserting two empty lines–––one spec fails.
Undo does not help when using guard.
focus/unfocus does not help.
Restarting guard does not help.
Running all specs and then running the 3 specs again does help and make them green again. But adding the other task makes two specs fail, again.
As one can see, some specs are red when run together with other specs. Even entering blank lines can make a difference.
More Observations
For some specs, passing or failing occurs randomly when run several times.
The behavior is not specific to one development machine but can be reproduced on travis.
To delete the database completely between the specs using database_cleaner does not help.
To Rails.cache.clear between the specs does not help.
Wrapping each spec in an ActiveRecord::Base.transaction does not help.
This does occur in Rails 4.0.0 as well as in Rails 4.1.1.
Using this minimal spec_helper.rb without spring or anything does not help.
Using guard vs. using bundle exec rspec some_spec.rb:123 directly doesn't make a difference.
This behavior goes for model specs, thus doesn't have to do anything with parallel database connections for features specs.
I've already tried to keep as many gems at the same version as in the (green) Rails-3.2 branch, including guard, rspec, factory_girl, etc.–––does not help.
Update: Observations Based on Comments & Answers
Thanks to engineerDave, I've inserted require 'pry'; binding.pry; into one of the concerning specs. Using the cd and show-source of pry, it was ingeniously easy and fun to narrow down the problem: Apparently, this has_many :through relation does not return objects when run together with other specs, even when called with (true).
has_many(:groups,
-> { where('dag_links.descendant_type' => 'User').uniq },
through: :memberships,
source: :ancestor, source_type: 'Group'
)
If I call groups directly, I get an empty result. But if I go through the memberships, the correct groups are returned:
#user.groups # => []
#user.groups(true) # => []
#user.memberships.collect { |m| m.group } # returns the correct groups
Has Rails changed the has many through behavior in Rails 4 in a way that could be responsible? (Remember: The spec works in isolation.)
Any help, insights and experiences are appreciated. Thanks very much in advance!
Code
Current master branch on Rails 3.2––all green.
Rails-4 branch––strange behavior.
The file/commit seen in the video––strange behavior.
All specs passing on travis for Rails 3.2.
Diff of the Gemfile.lock (or use git diff master..sf/rails4-minimal-update Gemfile.lock |grep rspec)
How to Reproduce
This is how one can check if the issue still exists:
Preparation
git clone git#github.com:fiedl/wingolfsplattform.git
cd wingolfsplattform
git checkout sf/rails4-minimal-update
bundle install
# please create `config/database.yml` to your needs.
bundle exec rake db:create db:migrate db:test:prepare
Run the specs
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb:213
The problem still exists, if the spec :213 is green in the second call but is red when run together with the other specs in the first call.
Based on that you're using:
the should syntax
that you indicate you've upgraded recently (perhaps a bundle update?)
that your failure messages indicate a NilObject error.
Is something like this perhaps what is causing it?
https://stackoverflow.com/a/16427072/793330
Are you are calling an object in your test which hasn't been instantiated yet?
I think this might be an rspec 3 upgrade issue where should is deprecated.
Have you ruled out an rspec gem upgrade to the new rspec 3 syntax (2.99 or 3.0.0+) as the culprit?
"Remove support for deprecated expect(...).should. (Myron Marston)"
IMO this behavior would not be caused by a Rails 4 update as its centered around your test suite.
Update (with pry debug):
Also you could use the pry gem to get a window into what is going on in your specs.
Essentially you can put a big "stop" sign (similar to a debug break) right before the spec executes to get a handle on the environment at that point.
it {
require 'pry'; binding.pry
should == something
}
Although beaware sometimes these pry calls wreck havoc on guard's threading and you have to kill it with CTRL+Z and then kill -9 PID that shows.
Update #2: Looking at updated answer.
You might be running up against FactoryGirl issues based on your has_many issue
You may need to trigger a before action in your Factory to pre-populate the associated record. Although this could get messy, i.e. here be monsters, you can trigger after and before callbacks in your factory that will bring these objects into being.
after(:create) do |instance|
do stuff here
end
Simply Running rails g from command line suffers from long time of pre-loading. I want to fast generate multiple migrations from a running rails c, so I tried:
require 'rails/generators'
Rails::Generators.invoke('migration',['user_book_list_followings'],{:behavior=>:invoke, :destination_root=>Rails.root})
You ask where did I get that :behavior and :destination_root arguments? Well, I pried at the Rails::Generators#invoke execution point when I run the generator from the command and recorded the exact arguments.
However, the funny thing was, I was presented with a error saying:
No value provided for required options '--orm'
Did I miss anything? (I was on Rails 3.2.3)
require 'rails/generators'
Rails::Generators.invoke("active_record:migration", ["create_something", "list_order:string", "name:string"], {migration: true, timestamps: true})
One solution to speed up callings rails g, is using spring.
Spring is a Rails application preloader. It speeds up development by keeping your application running in the background so you don't need to boot it every time you run a test, rake task or migration.
I am having many problems running DJ. Primarily, I cannot get delayed_job running any methods that change the database. I am testing locally with a sqlite3 database, DJ 3.0.0, and I even added the delayed_job_active_record gem.
I have, for example, tried to run the following method in the background:
#user = User.find(1)
#user.delay.recorder_method
Where this method is:
def recorder_method
self.relevant_field +=1
update
end
This creates a delayed job, and the handler has the appropriate info for the user and the appropriate method name. The script runs the job, thinks it has succeeded and thus deletes the record from the delayed_job table. BUT the user is unchanged (the database is unchanged).
What on earth is going wrong? Note that, when I run the same code ("#user.delay.recorder_method") from rails console, it works.. and the difference is the handler created by the rails console call is:
--- !ruby/object:Delayed::PerformableMethod
object: !ruby/ActiveRecord:User
attributes:
... (attribute info and rest of file)
Whereas the one created in by the call in a controller action is:
--- !ruby/struct:Delayed::PerformableMethod
object: !ruby/ActiveRecord:User
attributes:
Not the difference in line 1 of both things (ruby/object vs ruby/struct.. the former works and the latter doesn't). Maybe this is something that might signal what is going wrong. Any ideas, anybody?
Your Rails app is running an old version of the DJ gem and your console is running a new one. About six months ago, Delayed::PerformableMethod was refactored from a Struct into a regular class: https://github.com/collectiveidea/delayed_job/commit/7b8a79a72c0ee5d8bac4bc0b183d1cce9cedff85 (So your Rails app is running a gem at least six months old and your console is running one newer than that).
This is an easy fix. First update the appropriate line in your Rails Gemfile. You'll see a line like this:
gem 'delayed_job_active_record'
If it has a version specification, make sure it's updated to the newest. Then from the command line (in the Rails root), run:
bundle update delayed_job_active_record
For anyone interested, removing the following lines from boot.rb solved this issue for me:
require 'yaml'
YAML::ENGINE.yamler = 'syck'
I am apparently having a huge problem switching from the plugin version of Paperclip to the gem version in my app. It's been my impression that there should be no difference whatsoever between a plugin and a gem of a specified version. However, I'm not seeing this as an easy transition at all.
Rails 2.3.11, Ruby 1.8.7
The plugin version I am using is version 2.3.3 and was upgraded on August 2, 2010. Attempting to update this to the gem of the same version basically killed all my tests, not being able to load a factory model which did not have its attachment loaded. It appeared that validate_attachment_content_type was also attempting to validate the attachment presence, and couldn't find it, so everything just started breaking. Again, with the plugin there are no problems and I haven't had any problems in all this time we've been using it. On the other hand, this problem seems to not occur past version 2.3.4. That's a whole other set of problems.
Basically, in all versions from 2.3.4 and up I get the problem below:
can't convert nil into String
/home/joshua/.rvm/gems/ruby-1.8.7-p334#paperclip_upgrade/gems/paperclip-2.3.15/lib/paperclip/storage/s3.rb:163:in `extname'
/home/joshua/.rvm/gems/ruby-1.8.7-p334#paperclip_upgrade/gems/paperclip-2.3.15/lib/paperclip/storage/s3.rb:163:in `to_file'
/home/joshua/.rvm/gems/ruby-1.8.7-p334#paperclip_upgrade/gems/paperclip-2.3.15/lib/paperclip/attachment.rb:94:in `assign'
/home/joshua/.rvm/gems/ruby-1.8.7-p334#paperclip_upgrade/gems/paperclip-2.3.15/lib/paperclip.rb:279:in `avatar='
/home/joshua/railscamp/app/app/models/organization.rb:311:in `copy_membership'
in all my tests that access my organization model.
The apparent offending code in this case is attempting to clone a membership model from one organization to another, with the * line being the offending call.
def copy_membership(membership)
m = membership.clone
u = m.user.clone
u.organization = self
m.organization = self
begin
m.avatar = membership.avatar *
rescue RuntimeError
m.avatar = nil
end
m.user = u
m.save
m
end
Does this make any sense to anyone? Why would the plugin work, but the gem of the same version just wrecks everything?
Update: I also don't appear to have any paperclip rake tasks available. Any ideas?
As it turns out, we should have been checking whether the filename is valid or not, rather than depending on a generic runtime error for detecting avatar presence.
I been working on porting my application on "Rails 3.0.7" ,ever since I started to employ caching for my application either (file cache,memcache or any other) . I always happen to get the above error "can't dump File" .
I Google a bit and found that it has something to do with Marshal dump as ruby interpreter does allow Marshal dump of object that have Procs or lambdas in them so I looked upon my code but I could not find any Proc and lambda in my whole applications
Now to discover the problem I drill down the ActiveRecord 3.0.7 code and here are few interesting finding that I came up with
1 . "includes" in Rails 3 + internally call the define name scope OK this I give the answer that there is Proc and Lambada associated with the object so the error but this doesn't explain why the same code work sometime and report with errors(above errors) other times I mean If the error is for the Marshalling and object that hold a Proc or a Lambada then code should definitely not work and should always report errors no matter how many times the same code is ran but that not the case over here the code return errors sometimes and work well other times
Code
Rails.cache.fetch("accessible_websites_1")
{ Website.includes(:account) }
2 . If the ".includes" in Rails 3.0 + has problem then what up with other 'include' syntax does it too report error (above error)
so I ran the code with older syntax of include
Here is it
Rails.cache.fetch("accessible_websites_1")
{ Website.all(:include =>
:account) }
well surprisingly it ran but it never preloaded the account related for all the website ( which is where weird) but at least It never gave and error
so did a forensic on Active Record 3.0 + once again to discover how the older version of include(Rails 2.3 +) work surprise to know that the older version of include syntax internally call the .includes method of ActiveRecord 3.0 +
whoo How is that possible
two different syntax both call the same internal method one report with error sometimes ( not every time but preload the associated object) and other does not report with error but neither preload the associated object as said earlier.
OK , Hearing all this if anyone can help me out then I would be utmost grateful
By the way
Here what I'm trying to achieve
Rails.cache.fetch("accessible_websites_1")
{ Website.includes(:account) }
the equivalent code of above in Rails 2.3.5 and Rails 3 + (but does not preload the associated account object of all websites)
i.e
Rails.cache.fetch("accessible_websites_1")
{ Website.find(:all,:include =>
:account) }
Work perfectly fine without any issue
I using
Ruby = "ruby 1.8.7 (2010-01-10
patchlevel 249) [i486-linux]" Rails
= " Rails 3.0.7"
The same Problem even persisted on Rails 3.1.0
am I missing something
I can also provide the model structure if required
The problem is that
Website.includes(:account)
does not load the data, it just provides you with a proxy object that will load the objects on demand when you do something like calling #each or #to_s, if you force the fetching by adding a #to_aat the end it should work, e.g. try
Marshal.dump(Website.includes(:account))
Marshal.dump(Website.includes(:account).to_a)
#all(x=>y) does not do the same thing as #x(y), that is why you can do X.includes.joins.where but not X.all.where.
Not sure where the reference to a File comes from though.