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.
Related
I have upgraded my Ruby to 2.5 and after rectifying many dependency issues, I'm stuck at a place.
There is save method being called which saves the records, but somehow it do not works now and shows following error:
500 Internal Error
undefined method 'fetch_value' for #<Hash:0*0007e589e>
Did you mean fetch_values
each_value:
Earlier the same .save was working perfectly fine.
I've seen the same exception before. In my case, some ActiveRecord models were marshaled via Marshal::dump and saved as binary stream. Then, Ruby and Rails were upgraded.
Afterwards, calling Marshal::load on the marshaled copies would retrieve them and object.class would show the right model's name, but accessing any attribute within would throw the same exception.
I had to clear the marshaled copies and generate new ones.
I'm currently unable to use any of the active support time methods inside my ruby on rails 5.0 model like the following:
5.seconds
2.days
10.minutes
throws an error:
NoMethodError: undefined method `seconds' for AS::Duration:0x007f97a5903b90 #value=5, #parts=[[:seconds, 5]] Did you mean? send
EDIT: here is the actual code causing an issue.
ReminderJob.set(wait: 5.seconds).perform_later(self.user.id)
Even tho I can see people using the below code fine and it works
UserReminderJob.set(wait: 1.week).perform_later user
However, it works in my console and in my controllers and views.
The error message states that the object is AS::Duration:0x007f97a5903b90, NOT an integer -- therefore the example of 5.seconds will not reproduce the problem.
This is also unusual, since 5.seconds will normally return an ActiveSupport::Duration object, not AS::Duration.
I would therefore hazard a guess that you're actually using the as-duration ruby gem rather than built-in rails behaviour. This extends the the Integer class in a different way, and returns an object that doesn't behave like an integer.
I think that an actual reproduction of your error could be achieved with: 5.seconds.seconds. In standard rails, this works fine (and returns the same value as 5.seconds), since ActiveSupport::Duration instances behave like Integers. But with this gem, it fails with the above error.
When replicating an app to production, my POSTGIS table columns started misbehaving, with Rails informing me there was an "unknown OID 26865" and that the fields would be treated as String.
Instead of current_pos yielding e. g.
#<RGeo::Geographic::SphericalPointImpl:0x22fabdc "POINT (13.39318248760133 52.52908798020595)"> I would get 0101000020E6100000FFDD958664C92A403619DEE6B2434A40. It looked like the activerecord-postgis-adapter was not installed, or installed badly, but I eliminated that possibility by testing for the existence of data type RGeo::Feature::Point and by test-assigning
current_pos = "POINT (13.39318248760133 52.52908798020595)"
to the field - which proceeded without error but then yielded another incomprehensible hex string like the above.
Also, strangely enough, POSTGIS was working correctly within the database, e.g. giving correct results for a ST_DISTANCE query. A very limited problem thus, where writing, writing-parsing (from Point to hex format), manipulating by SQL and reading all worked, only the parsing upon read didn't.
When I tried to use migrations to ensure the database column would have the correct type, the migrations failed, giving
undefined method `st_point' for #<ActiveRecord::ConnectionAdapters::PostgreSQL::TableDefinition:0x00000005cb80b8>
I spent several hours trying all kinds of solutions, even re-installing the server from scratch, double-checking version numbers of everything, installing a slightly newer version of Ruby and a slightly older version of POSTGIS (to match my other environment), exporting the database and starting with a clean one, and so on. After I had done migrations and arrived at the "undefined method st_point" error, I was finally able to find the solution via Google, way down in a Github issue, and it's really simple:
In config/database.yml, swap out postgres:// for postgis:// in the database url. If you're using Heroku, this may require some ugly manipulation:
production:
url: <%= ENV.fetch('DATABASE_URL', '').sub(/^postgres/, "postgis") %>
So silly...
Do not forget to add activerecord-postgis-adapter to your Gemfile so #Sprachprofi's solution can run.
I have been chasing an issue down for a while now, and still cannot figure out what's happening. I am unable to edit documents made from my gem through normal persistence methods, like update or even just editing attributes and calling save.
For example, calling:
Scram::Policy.where(id: a.id).first.update!(priority: 12345)
Will not work at all (there are no errors, but the document has not updated). But the following will work fine:
Scram::Policy.collection.find( { "_id" => a.id } ).update_one( { "$set" => {"priority" => 12345}})
I am not sure what I'm doing wrong. Calling update and save on any other model works fine. The document in question is from my gem: https://github.com/skreem/scram/blob/master/lib/scram/app/models/policy.rb
I cannot edit its embedded documents either (targets). I have tried removing the store_in macro, and specifying exactly what class to use using inverse_of and class_name in a fake app to reimplement these classes: https://github.com/skreem/scram-implementation/blob/master/lib/scram/lib/scram/app/models/policy.rb
I've tried reimplementing the entire gem into a clean fake rails application: https://github.com/skreem/scram-implementation
Running these in rails console demonstrates how updating does not work:
https://gist.github.com/skreem/c70f9ddcc269e78015dd31c92917fafa
Is this an issue with mongoid concerning embedded documents, or is there some small intricacy I am missing in my code?
EDIT:
The issue continues if you run irb from the root of my gem (scram) and then run the following:
require "scram.rb"
Mongoid.load!('./spec/config/mongoid.yml', :test)
Scram::Policy.first.update!(priority: 32) #=> doesn't update the document at all
Scram::Policy.where(id: "58af256f366a3536f0d54a61").update(priority: 322) #=> works just fine
Oddly enough, the following doesn't work:
Scram::Policy.where(id: "58af256f366a3536f0d54a61").first.update(priority: 322)
It seems like first isn't retrieving what I want. Doing an equality comparison shows that the first document is equal to the first returned by the where query.
Well. As it turns out, you cannot call a field collection_name or else mongoid will ensure bad things happen to you. Just renaming the field solved all my issues. Here's the code within mongoid that was responsible for the collision: https://github.com/mongodb/mongoid/blob/master/lib/mongoid/persistence_context.rb#L82
Here's the commit within my gem that fixed my issue: https://github.com/skreem/scram/commit/25995e955c235b24ac86d389dca59996fc60d822
Edit:
Make sure to update your Mongoid version if you have dealt with this issue and did not get any warnings! After creating an issue on the mongoid issue tracker, PersistenceContext was added to a list of prohibited methods. Now, attempting to use collection_name or collection as a field will cause mongoid to spit out a couple of warnings.
Fix commit: https://github.com/mongodb/mongoid/commit/6831518193321d2cb1642512432a19ec91f4b56d
I previously posted a question (Performing multiple queries on the same model efficiently) which fellow StackExchange users kindly answered and saved me lots of processing time, avoiding lots of queries on my model by storing the results of a SQL query using the .all function
Specifically they advised #chosenrecords = Everything.where('name LIKE ?', 'What I want').order('price ASC').all be used
This appeared to work fantastically and I used it in a number of places in our code, however, having just uploaded it onto a live server I get an error message from Phusion Passenger for every line in which .all features.
The error is syntax error, unexpected '.', expecting kEND .order('price ASC').all
I have previously tried to gather information from the company hosting our sites regarding the versions of rails and passenger they're using, but without any success. In the past anything that has worked locally has also worked on the server, provided I use Ruby 1.9.3 i386-mingw32.
Can anyone advise how I could fix this error? Is there an older function that does the equivalent operation and may work on the server?
Discovered that the old version of Passenger appears to be less robust to code falling across 2 lines, essentially I changed
#chosenrecords = Everything.where('name LIKE ?', 'What I want')
.order('price ASC').all
to the following and it works a dream
#chosenrecords = Everything.where('name LIKE ?', 'What I want').order('price ASC').all
Hopefully someone else will benefit from the errors of my ways!
Actually that's not a Passenger problem, nor is it a matter of "less robust to code falling across 2 lines". The problem is this:
The first code exhibit is illegal Ruby syntax. If you to chain a to #order like that, you have to ensure that the first line ends with a dot. Otherwise Ruby will think that the first line is a single, complete statement, with the second one also being a single complete statement. Obviously a Ruby statement cannot begin with a dot, so in your first code exhibit, the second line raises a syntax error.