Have somebody tried to rewrite CanCan ActiverRecordAddtions for
Mongoid http://github.com/ryanb/cancan/blob/master/lib/cancan/active_record_additions.rb
Regards,
Alexey Zakharov
I've managed to get CanCan and Mongoid (version 2) to work together pretty well on a rails 3 app. Still get some errors here and there related to conditions in the permission definition (the Ability model).
I just put the contents of this gist into a file in config/initializers:
http://gist.github.com/561639
The condition hashes are almost the same as with ActiveRecord:
# can only manage own account
can :manage, User, :_id => current_user.id
I'm still working on how to use more advanced Mongoid::Criteria conditions, but you can always use a block to do more complex conditions:
# can only manage own account
can :eat, Cake do
current_user.jobs.any?{ |job| job.title == 'Peasant'}
end
I know it's an old one, but for those who search mongoid and cancancan integration, you could try official mongoid adapter
For cacancan gem version >2.0 there's separate gem cancacan-mongoid
Bear in mind that this gem status is "in development", but still it's working pretty well and build passing
Related
I want to develop a rubygem which is intended to be installed in a rails application.
The gem will contain few models and their database migrations.
Also I would like to add tests asserting the models and their relationships. I prefer RSpec for doing that.
While I was about to start I got stuck with a question that how to use ActivRecord in a gem so that using the tests I can insert the fixture data and test the relationships and behaviour.I believe SQLite should prove to be the best option for database here.
Note: I haven't developed any Rubygem before and this will be the first one I am attempting. Thus any help will be highly appreciated to guide me in the right direction.
Thanks.
Update on Jul 30, 2018
I found a similar question Ruby Gem Development - How to use ActiveRecord? which is exactly what I want to do. But the answers are not quite clear. Hope this helps in understanding my question.
You can get the functionality you are looking for using generators. Basically you write templates for the files that the user should have (models, migrations, tests) and save them with your gemfile. You then allow the user to copy those files in using commands.
This is a good link that goes into much more detail on generators, but here is a small example that I used in one of my gems:
gem_name/lib/generators/gem_name/install_generator.rb
module GemName
class InstallGenerator < Rails::Generators::Base
include Rails::Generators::Migration
# Allow user to specify a different model name
argument :user_class, type: :string, default: "User"
# Templates to copy
source_root File.expand_path('../../../templates', __FILE__)
# Copy initializer into user app
def copy_initializer
copy_file('create_initializer.rb', 'config/initializers/gem_name.rb')
end
# Copy user information (model & Migrations) into user app
def create_user_model
fname = "app/models/#{user_class.underscore}.rb"
unless File.exist?(File.join(destination_root, fname))
template("user_model.rb", fname)
else
say_status('skipped', "Model #{user_class.underscore} already exists")
end
end
# Copy migrations
def copy_migrations
if self.class.migration_exists?('db/migrate', "create_gem_name_#{user_class.underscore}")
say_status('skipped', "Migration create_gem_name_#{user_class.underscore} already exists")
else
migration_template('create_gem_name_users.rb.erb', "db/migrate/create_gem_name_#{user_class.pluralize.underscore}.rb")
end
end
private
# Use to assign migration time otherwise generator will error
def self.next_migration_number(dir)
Time.now.utc.strftime("%Y%m%d%H%M%S")
end
end
end
Finally, just some advice/personal opinion; your gem should either run under a variety of test suites and databases or else you should indicate that you only support that setup and assume they are available in the user's project. Though I think you could shoehorn in a second test suite, trying to force a second database wouldn't be possible, also you don't need to worry about the DB using migrations unless you want to use a data type that isn't available in all the supported DBs.
A better approach, in my opinion, would be to write separate generators for the specs you want and let the user run them optionally. This will copy the tests in and allow them to modify if they like.
I'd like to use a database within a Ruby gem that I'm writing. The gem is meant to be used within Rails applications, and will contain an inverted index of documents passed in from the main Rails app.
I'm a bit confused as to how to go about this. Should I hook into the main Rails database somehow? Or should I have a standalone database? Ideally I'd just like to use ActiveRecord to create, update, delete and query entries but I am not sure how I'd set this up.
Data would go into the database at this point:
module ActiveRecordExtension
extend ActiveSupport::Concern
class_methods do
def foo
"bar"
end
end
included do
after_save :add_to_inverted_index
end
def add_to_inverted_index
# This is where I'd take the fields from the Rails app
# and include them to my inverted index. However, I'm struggling
# to find a way to hook into a database from my gem to do this.
end
end
# Include the extension
ActiveRecord::Base.send(:include, ActiveRecordExtension)
Suggestions are much appreciated! Thanks
Well after your clarification, you should use main Rails database. Just create a migration and insert the table(s) you need. You should do that because:
Everyone that uses your gem will know what is stored at the database.
With migrations, you can easily rollback the migration, making it simple to reverse something, if needed.
There's no need to create extra dependencies. Imagine a project that you did in RoR and think if the mess it would be if every gem that you used created its own database.
Maybe you should take a look at known gems and how they do that. I'm thinking about Devise.
I am upgrading from Rails 3.2 to 4.2 and wanted to follow Ryan Bates' advice of getting things working as quickly as possible before doing any major refactoring.
To that end, I installed the protected_attributes gem because I was under the impression that with this gem installed I wouldn't need to implement the strong params approach in my controllers immediately and could continue using attr_accessible in the models until I have time to refactor.
I'm not getting any errors about attr_accessible itself, but when I try to create a user in development I get Unpermitted parameters: first_name, last_name, phone despite having all of those as arguments in the User model's attr_accessible method.
Can someone point out what I'm doing wrong here?
That's not the correct approach. Instead of porting a legacy, deprecated feature from 3.2 to 4.2, what you really want to do instead is the opposite: install strong_parameters gem in Rails 3.2 and make sure to replace the attr_accessible before the upgrade.
Rails 4.x is not really designed to use protected attributes anymore, therefore you will encounter a lot of issues trying to reintroduce it.
To use strong params you will have to update your controller's code (which is what I recommend to do, since it won't cost too much work).
In general the implementation of using strong_parameters is as follows:
def create
#model = Model.create(model_params)
if #model.persisted?
# logic
else
#logic
end
end
private
def model_params
params.require(:model).permit(:model_attrbite1, :model_attribute2)
end
I am using the geokit gem and plugin with rails 3. It seems there is a known issue with them, which can be seen here http://github.com/andre/geokit-rails/issues#issue/15
Now, I tried to follow the solution provided at the bottom. I pasted that function definition, at the end of the file, just above acts_as_mapable, and just after the first time it was called, but nothing happened each time.
Any idea what else can be done?
Thanks
I ran into similar problems upgrading my app to rails 3. I'm still using Geokit for geocoding but Active Record scopes for distance based database queries. It's pretty convenient, and you still get all of the Active Record 3 goodness. Here's an example from my User model:
scope :near, lambda{ |*args|
origin = *args.first[:origin]
if (origin).is_a?(Array)
origin_lat, origin_lng = origin
else
origin_lat, origin_lng = origin.lat, origin.lng
end
origin_lat, origin_lng = deg2rad(origin_lat), deg2rad(origin_lng)
within = *args.first[:within]
{
:conditions => %(
(ACOS(COS(#{origin_lat})*COS(#{origin_lng})*COS(RADIANS(users.lat))*COS(RADIANS(users.lng))+
COS(#{origin_lat})*SIN(#{origin_lng})*COS(RADIANS(users.lat))*SIN(RADIANS(users.lng))+
SIN(#{origin_lat})*SIN(RADIANS(users.lat)))*3963) <= #{within}
),
:select => %( users.*,
(ACOS(COS(#{origin_lat})*COS(#{origin_lng})*COS(RADIANS(users.lat))*COS(RADIANS(users.lng))+
COS(#{origin_lat})*SIN(#{origin_lng})*COS(RADIANS(users.lat))*SIN(RADIANS(users.lng))+
SIN(#{origin_lat})*SIN(RADIANS(users.lat)))*3963) AS distance
)
}
}
Here's a blog post with a little more detail on the subject: http://stcorbett.com/code/distance-queries-with-rails-3-without-geokit/
jlecour's port to rails 3 should solve any issues you were having last year.
Make sure you're using mysql or postgres if you're doing distance calculations.
After trouble installing the geokit-rails3 gem on Rails 3.1 I moved to the geocoder gem. It has distance calculation as well (be sure to not forget the s in #your_model.nearby*s*(5)). There is also a Railscast.
Here is port of geokit to rails 3, incomplete through:
https://github.com/jlecour/geokit-rails3
For those still having trouble with geokit, i moved on to using mongodb... which has inbuilt distance search n all...
Hey Amit, Not sure if you sorted this out yet but I'll tell you what I did just in case.
I forked andre's geokit-rails source and then cloned it locally and added the code from this gist at line 34 of lib/geokit-rails/acts-as-mappable.rb, just after the line that reads module ClassMethods # :nodoc:.
Then I commited those changes back to my forked repo on github and used my fork to install the source as a plugin to my rails 3 app. That seemed to work straight away, but make sure you have the acts_as_mappable line added to whatever model you are wanting to do distance calculations on and make sure you have two float columns on that db named :lat and :lng.
I am a beginner in Rails. I use 2.3.X.
I just saw Rails 3 is pre-released [edit: now in release candidate!]. I will most probably eventually switch to it.
What are the common coding habits in 2.3 I should not take, so that the switch is as smooth as possible ?
Edit:
I've done my homework and read the Release notes. But they are far from clear for the most crucial points, for example :
1.5 New APIs
Both the router and query interface have seen significant, breaking changes. There is a backwards compatibility layer that is in place and will be supported until the 3.1 release.
This is not comprehensive enough for a beginner like me. What will break ? What could I do already in 2.3.X to avoid having troubles later ?
Looking at my personal coding habits (I have been using Rails since 1.2.x), here's a list of API changes you can anticipate according to Rails 3 release notes.
find(:all)
Avoid the usage of:
Model.find(:all)
Model.find(:first)
Model.find(:last)
in favour of:
Model.all
Model.first
Model.last
Complex queries
Avoid the composition of complex queries in favor of named scopes.
Anticipate Arel
Rails 3 offers a much cleaner approach for dealing with ActiveRecord conditions and options. You can anticipate it creating custom named scopes.
class Model
named_scope :limit, lambda { |value| { :limit => value }}
end
# old way
records = Model.all(:limit => 3)
# new way
records = Model.limit(3).all
# you can also take advantage of lazy evaluation
records = Model.limit(3)
# then in your view
records.each { ... }
When upgrading to Rails 3, simply drop the named scope definition.
Constants
Avoid the usage of the following constants in favour of the corresponding Rails.x methods, already available in Rails 2.x.
RAILS_ROOT in favour of Rails.root,
RAILS_ENV in favour of Rails.env, and
RAILS_DEFAULT_LOGGER in favour of Rails.logger.
Unobtrusive Javascript
Avoid heavy JavaScript helpers in favour of unobtrusive JavaScript.
Gem dependencies
Keep your environment.rb as clean as possible in order to make easier the migration to Bundler. You can also anticipate the migration using Bundler today without Rails 3.
The release notes are the most important thing to keep an eye on. Other than that Jeremy McAnally has some neat blog posts about the whole Rails 3 thing (and has just released a gem to help you with the migration).
I'd say, read the rails release notes and see for yourself what seems the more surprising to you. A lot of stuff changed so reading this is definitively very important.