I have a bunch of derived classes that only differ by the static methods.
(It's Ruby, but question is not about Ruby, it's about the design.)
class Exporter
def export
# ...
end
end
class ExporterA < Exporter
def from
'aaa_table'
end
def fields
['a1', 'a2', 'a3']
end
def to
'aaa_file'
end
end
class ExporterB < Exporter
def from
'bbb_table'
end
def fields
['b1', 'b2', 'b3']
end
def to
'bbb_file'
end
end
So, I looked at this and came up with idea of placing all this static data to some kind of a table and just use Exporter with the appropriate attributes. In this case, I would need some kind of ExporterFactory class which is going to know who is who and how to create the A and B exporters.
class ExporterFactory
def _table
return {
:a => {
:from => 'aaa_table',
:fields => ['a1', 'a2', 'a3'],
:to => 'aaa_file',
},
:b => {
:from => 'bbb_table',
:fields => ['b1', 'b2', 'b3'],
:to => 'bbb_file',
},
}
end
def create(type)
return Exporter.new(self._table[type])
end
end
Again, I looked at this and now I don't really like this approach. Reasons:
My real data for _table is much bigger so my table looks heavy and ugly.
Now you can create Exporters that don't really make sense.
It looks like the factory knows too much, I would prefer to have data about A-export encapsulated in ExporterA.
I can't decide. The second approach seems more logical, but I still want to use the first one. My main idea is “I want to use inheritance just to organize that big and ugly table”.
What should I choose? What kind of problems I'm going to have in each of that ways?
I agree that your Factory knows too much, meaning that it has to change every time any Exporter changes. Also, if you ever have an Exporter that needs additional code, there will be no way to create it. Your first design allows you to write Exporters that override superclass methods if you ever need them.
You could make your first design more succinct by putting the data in initialize and overriding that rather than three methods:
class Exporter
attr_accessor :from, :fields, :to
def initialize(from, fields, to)
self.from = from
self.fields = fields
self.to = to
end
def export
# ...
end
end
class ExporterA < Exporter
def initialize
super 'aaa_table', ['a1', 'a2', 'a3'], 'aaa_file'
end
end
class ExporterB < Exporter
def initialize
super 'bbb_table', ['b1', 'b2', 'b3'], 'bbb_file'
end
end
Related
I've got two models.
Class ModelA < ActiveRecord::Base
has_many :model_bs
end
Class ModelB < ActiveRecord::Base
belongs_to :model_a
def as_json(options = {})
{
:whatever => 'hello world'
}
end
end
When I call model_a.as_json(:include => :model_b), I want it to return a json which includes all model_bs, which it does, but employing my as_json redefinition, which it does not as it just uses the default one. Is there any way to use my own method rather than the original one? Thanks
In Rails 3, as_json method invokes serializable_hash to obtain the attributes hash. And they share the same 'options' parameter. In your case, overwritting serializable_hash would give the expected result.
def serializable_hash(options = {})
{:whatever => 'hello world'}
end
But, My suggestion is that instead of overwriting the convention, operate on the result of "super", which is like:
def serializable_hash(options = {})
hash = super
has[:name] = "hello world"
hash
end
I want to use FactoryGirl.attributes_for in controller testing, as in:
it "raise error creating a new PremiseGroup for this user" do
expect {
post :create, {:premise_group => FactoryGirl.attributes_for(:premise_group)}
}.to raise_error(CanCan::AccessDenied)
end
... but this doesn't work because #attributes_for omits the :user_id attribute. Here is the difference between #create and #attributes_for:
>> FactoryGirl.create(:premise_group)
=> #<PremiseGroup id: 3, name: "PremiseGroup_4", user_id: 6, is_visible: false, is_open: false)
>> FactoryGirl.attributes_for(:premise_group)
=> {:name=>"PremiseGroup_5", :is_visible=>false, :is_open=>false}
Note that the :user_id is absent from #attributes_for. Is this the expected behavior?
FWIW, my factories file includes definitions for :premise_group and for :user:
FactoryGirl.define do
...
factory :premise_group do
sequence(:name) {|n| "PremiseGroup_#{n}"}
user
is_visible false
is_open false
end
factory :user do
...
end
end
Short Answer:
By design, FactoryGirl's attribues_for intentionally omits things that would trigger a database transaction so tests will run fast. But you can can write a build_attributes method (below) to model all the attributes, if you're willing to take the time hit.
Original answer
Digging deep into the FactoryGirl documentation, e.g. this wiki page, you will find mentions that attributes_for ignores associations -- see update below. As a workaround, I've wrapped a helper method around FactoryGirl.build(...).attributes that strips id, created_at, and updated_at:
def build_attributes(*args)
FactoryGirl.build(*args).attributes.delete_if do |k, v|
["id", "created_at", "updated_at"].member?(k)
end
end
So now:
>> build_attributes(:premise_group)
=> {"name"=>"PremiseGroup_21", "user_id"=>29, "is_visible"=>false, "is_open"=>false}
... which is exactly what's expected.
update
Having absorbed the comments from the creators of FactoryGirl, I understand why attributes_for ignores associations: referencing an association generates a call to the db which can greatly slow down tests in some cases. But if you need associations, the build_attributes approach shown above should work.
I think this is a slight improvement over fearless_fool's answer, although it depends on your desired result.
Easiest to explain with an example. Say you have lat and long attributes in your model. On your form, you don't have lat and long fields, but rather lat degree, lat minute, lat second, etc. These later can converted to the decimal lat long form.
Say your factory is like so:
factory :something
lat_d 12
lat_m 32
..
long_d 23
long_m 23.2
end
fearless's build_attributes would return { lat: nil, long: nil}. While the build_attributes below will return { lat_d: 12, lat_m: 32..., lat: nil...}
def build_attributes
ba = FactoryGirl.build(*args).attributes.delete_if do |k, v|
["id", "created_at", "updated_at"].member?(k)
end
af = FactoryGirl.attributes_for(*args)
ba.symbolize_keys.merge(af)
end
To further elaborate on the given build_attributes solution, I modified it to only add the accessible associations:
def build_attributes(*args)
obj = FactoryGirl.build(*args)
associations = obj.class.reflect_on_all_associations(:belongs_to).map { |a| "#{a.name}_id" }
accessible = obj.class.accessible_attributes
accessible_associations = obj.attributes.delete_if do |k, v|
!associations.member?(k) or !accessible.include?(k)
end
FactoryGirl.attributes_for(*args).merge(accessible_associations.symbolize_keys)
end
Here is another way:
FactoryGirl.build(:car).attributes.except('id', 'created_at', 'updated_at').symbolize_keys
Limitations:
It does not generate attributes for HMT and HABTM associations (as these associations are stored in a join table, not an actual attribute).
Association strategy in the factory must be create, as in association :user, strategy: :create. This strategy can make your factory very slow if you don't use it wisely.
The accepted answer seems outdated as it did not work for me, after digging through the web & especially this Github issue, I present you:
A clean version for the most basic functionality for Rails 5+
This creates :belongs_to associations and adds their id (and type if :polymorphic) to the attributes. It also includes the code through FactoryBot::Syntax::Methods instead of an own module limited to controllers.
spec/support/factory_bot_macros.rb
module FactoryBot::Syntax::Methods
def nested_attributes_for(*args)
attributes = attributes_for(*args)
klass = args.first.to_s.camelize.constantize
klass.reflect_on_all_associations(:belongs_to).each do |r|
association = FactoryBot.create(r.class_name.underscore)
attributes["#{r.name}_id"] = association.id
attributes["#{r.name}_type"] = association.class.name if r.options[:polymorphic]
end
attributes
end
end
this is an adapted version of jamesst20 on the github issue - kudos to him 👏
I'm using Rails 3.1 and Mongoid. What would be the proper way to enforce that a field of my model is saved to lowercase? I don't see this in the Mongoid documentation but I was wondering if there is a clean way I should know about. Thanks much.
Ok so I read the documentation more thoroughly, which I should have done initially. And this works for me now.
in the model.rb:
...
before_create :drop_the_case
protected
def drop_the_case
self.MYMODELFIELD = self.MYMODELFIELD.downcase
end
"drop_the_case" being my own arbitrary name for this.
Thanks.
In your model you can use
def before_save
self.your_model_field = your_model_field.downcase
end
or
def before_save
self.your_model_field.downcase!
end
Take a look at http://www.ruby-forum.com/topic/109091 This should work !!
The accepted answer with the before_create callback has some big issues, especially if you use certain constraints like validates_uniqueness_of. Use the before_validation callback instead when possible.
class Safe
include Mongoid::Document
field :foo, type: String
validates_uniqueness_of :foo
before_validation :drop_the_case
protected
def drop_the_case
self.foo = self.foo.downcase
end
end
class Dangerous
include Mongoid::Document
field :foo, type: String
validates_uniqueness_of :foo
before_create :drop_the_case
protected
def drop_the_case
self.foo = self.foo.downcase
end
end
dangerous = Dangerous.create!(name: 'BAR')
safe = Safe.create!(name: 'BAR')
dangerous.update(name: 'BAR') # dangerous.name => BAR
safe.update(name: 'BAR') # safe.name => bar
Dangerous.create!(name: 'BAR') # => true, unique constraint ignored
Safe.create!(name: 'BAR') # throws exception
I'm building a user ranking system, and am trying to assign user.rank values with a name.
I wanted to define something like this in my User model and then be able to reference it when displaying each user's rank, but this probably isn't the best way:
class User < ActiveRecord::Base
RANK_NAMES = {
'Peasant' => (0..75),
'Craftsman' => (76..250),
'Vassal' => (251..750),
'Noble' => (750..1500),
'Monarch' => (1501..999999)
}
Perhaps it would be better to define a method in a controller or helper like:
if user.rank == 0..75
rank_name = "Peasant"
elsif...
But not sure how to do that. Anyone have any thoughts? I'm not even sure what to call what it is I'm trying to do, thus making it difficult to research on my own.
It could be something even as simple as this, assuming user.rank exists.
class User < ActiveRecord::Base
...
def rank_name
case self.rank
when 0..75
'Peasant'
when 76..250
'Craftsman'
when 251..750
'Vassal'
when 750..1500
'Noble'
when 1501..999999
'Monarch'
end
end
...
end
If rank_name is specific to the User, I'd make it a method of User.
You could try something like below. It might give you some ideas.
class User
RANKS = [
{:name => 'Peasant', :min => 0, :max => 75},
{:name => 'Craftsman', :min => 76, :max => 250}
# ...
]
attr_accessor :rank
def rank_name
# TODO what happens if rank is out of range of all ranks or rank is nil
# or not an integer
User::RANKS[rank_index][:name]
end
private
def rank_index
User::RANKS.index { |r| (r[:min]..r[:max]).include? #rank }
end
end
user = User.new
user.rank = 76
puts user.rank_name # -> Craftsman
using ruby 1.9.2 and rails 3, i would like to limit the fields returned when a record is accessed as json or xml (the only two formats allowed).
this very useful post introduced me to respond_with and i found somewhere online that a nice way to blanket allow/deny some fields is to override as_json or to_xml for the class and set :only or :except to limit fields.
example:
class Widget < ActiveRecord::Base
def as_json(options={})
super(:except => [:created_at, :updated_at])
end
def to_xml(options={})
super(:except => [:created_at, :updated_at])
end
end
class WidgetsController < ApplicationController
respond_to :json, :xml
def index
respond_with(#widgets = Widgets.all)
end
def show
respond_with(#widget = Widget.find(params[:id]))
end
end
this is exactly what i am looking for and works for json, but for xml "index" (GET /widgets.xml) it responds with an empty Widget array. if i remove the to_xml override i get the expected results. am i doing something wrong, and/or why does the Widgets.to_xml override affect the Array.to_xml result?
i can work around this by using
respond_with(#widgets = Widgets.all, :except => [:created_at, :updated_at])
but do not feel that is a very DRY method.
In your to_xml method, do the following:
def to_xml(options={})
options.merge!(:except => [:created_at, :updated_at])
super(options)
end
That should fix you up.