it sounds like not difficult at all but after looking for a while I can't find a way to change the limit of the closest scope in Geokit-rails.
I've tried to overide the definition of this method which is defined according to the documentation as:
def closest(options = {})
geo_scope(options).order("#{distance_column_name} asc").limit(1)
end
but with no success.
Any idea? Thank you very much!
That's an older version of geokit-rails/geokit, now the definition is:
def closest(options = {})
by_distance(options).first(1)
end
So no need to override anything, your code could simply say:
MyClass.by_distance(options).limit(my_limit)
Note: Try to avoiding monkey patching existing code. If you did what was suggested in another comment it might work now, but as soon as you update geokit/geokit-rails you risk it breaking as implementations do change (e.g. the closest method is implemented rather differently.
You can override this method, something like:
module Geokit
def closest(options = {})
geo_scope(options).order("#{distance_column_name} asc").limit(options[:limit] || 1)
end
end
and put this file in config/initializers folder and restart server. Note: put correct module name, classes. Consider it like a path to method.
Related
I have a controller object with controller.class == Admin::TeamsController. I might also have a circumstance like controller.class == Admin::UsersController. Now I want to check if this is true:
controller.class.to_s.match?('Admin::')
I.e., I want to know: Is this object of a class that's defined within the Admin module namespace? To spell that out, is the structure like the following?
module Admin
module SomeOtherModulePerhaps
class TeamsController
end
end
end
My question: Is there a nicer Ruby way to test for this? It feels kind of hacky to convert the class to a string, then do a regex match like that.
EDIT:
For my constrained use case, I could check like this:
controller.class.to_s.split('::').first == 'Admin'
But that doesn't quite solve the general case that other people might have. For example, there might be cases like XyzAdmin::TeamsController that one might want to exclude, on which my first solution fails, or Foo::Admin::TeamsController that one might want to include, on which my second solution fails.
I'd like to find a better way.
Rails comes with module_parents:
module Admin
module SomeOtherModulePerhaps
class TeamsController
end
end
end
controller = Admin::SomeOtherModulePerhaps::TeamsController.new
controller.class.module_parents
#=> [Admin::SomeOtherModulePerhaps, Admin, Object]
controller.class.module_parents.include?(Admin)
#=> true
Under the hood, it uses Module#name, i.e. "Admin::SomeOtherModulePerhaps::TeamsController".
How about
controller.class.const_defined?(:Admin)
returns true or false
What about to use controller_path
https://api.rubyonrails.org/classes/AbstractController/Base.html#method-c-controller_path
controller_path.match?('admin')
You might try playing with Module#nesting, but it’d return rather unexpected results depending on whether the class was defined using fully qualified name or a set of nesting statements.
After all, class names in ruby are simple constants, and one might define the class name in many ways, like:
module A
def self.class!
Class.new do |c|
define_method :test do puts c.name end
end
end
end
A.const_set :C, A.class!
#⇒ A::C
A::C.new.test
#⇒ A::C
Which roughly means, there are tons of ways to fool the best detection mechanism. That said, I’d go with the easiest one.
controller.class.to_s.split('::')[0...-1].include?('Admin')
Any occurrence of Admin would be counted, save for when Admin is the last item in the class name chain.
I want to know: Is this object of a class that's defined within the Admin module namespace?
[...]
Is there a nicer Ruby way to test for this?
Classes aren't defined in modules, therefore, there is neither a nice way nor any other way to test for it.
When you write a class definition body inside a module definition body, you do not create any relationship whatsoever between the module and the class. The only relationship is between the constant that the class gets assigned to and the module, not the class.
Therefore, since this relationship does not exist, you cannot test for it.
I have a monkeypatched of ActiveRecord find with some business logic, for example:
# lib/core_extensions/active_record/finder_methods/finder.rb
module ActiveRecord
module FinderMethods
def find(*args)
return super if block_given?
#... business logic code => my_error_control = true
raise "My Error" if my_error_control
retorn = find_with_ids(*args)
end
end
end
retorn
I have not seen many examples like this, and this causes me a doubt:
Where should finder.rb be?
In this example, this file is in lib/core_extensions/... but if it contains business logic, I think finder.rb should lives in the folder app/core_extensions/ isn't it?
Edited, after Sergio Answer
things like this, are a bad practice?
# lib/core_extensions/nil_class/image_attributes.rb
# suport for product images attributes
class NilClass
def main_image(size,evita_video)
"/images/paperclip_missing/original/missing.png"
end
end
Where should finder.rb be?
Ultimately, it doesn't matter. It only matters that this code gets loaded. This mix of patching base libraries and adding business logic there looks like something that MUST be documented thoroughly (in the project's wiki or something like that). And if it is documented, then it doesn't matter. The code is where the documentation says it is.
That being out of the way, here's a design suggestion:
when user seeks a Family Family.find(params[family_id],session[:company_id]), this find will compare the company of the family result family.company witht the parameter
Why not do something like this:
family = current_company.families.find(params[:family_id])
where current_company can be defined as #current_company ||= Company.find(session[:company_id])
Here, if this company doesn't have this family, you'll get an exception.
Same effect*, only without any patching. Much more futureproof. You can even add a couple of rubocop rules to ensure that you never write a naked Family.find.
* it's not like you add that patch and rest of your code magically acquires super-powers. No. You still have to change all the finders, to pass that company id.
It's the first time I see such case :). I'd put it in app/core_extensions and check if live reloading works correctly with it. If not, I'd move it to lib/. (It's just a heuristic)
Edit:
Instead of extending NilClass I'd rather use regular NullObjects. It's really less surprising and easier to understand.
https://robots.thoughtbot.com/rails-refactoring-example-introduce-null-object
In ruby, I'm starting to see a pretty normal practice including modules and mixins referenced as ::ModuleName::ClassName, where in the past it was pretty much just ModuleName::ClassName.
What I'd like to get here is a decent understanding of why this practice is being seen more lately and what it does differently.
What's the difference?
What's the benefit (if the prior doesn't answer this)?
Thanks in advance for your input.
If you put the :: in the beginning you are referring to the global namespace, if you don't you are referring to your current namespace.
Usually if you don't have a class/module with the same name inside your class/module you would not need to use the :: in the beginning.
class Customer
def to_s
"Customer global"
end
end
class Order
class Customer
def to_s
"Customer within order"
end
end
def initialize
puts Customer.new
puts ::Customer.new
end
end
Order.new
will print out
Customer within order
Customer global
When you do ::ModuleName::ClassName you're saying:
I want you to look for ::ModuleName::ClassName at the root namespace, ignoring if this code is found inside another module. So, it will always look for a class that's named as ::ModuleName::ClassName and nothing else
When you say it like this ModuleName::ClassName, you're saying:
I want you to look for ModuleName::ClassName but looking at the current scope first and then at the other scopes. So, if you have a module called MyModule and this my module references ModuleName::ClassName then first try to find MyModule::ModuleName::ClassName then try to resolve ::ModuleName::ClassName.
When I'm defining code like this I almost always use ::ModuleName::ClassName to avoid any naming conflicts.
Something like this:
class Category
SOME_CATEGORY = find_by_name("some category")
end
Category::SOME_CATEGORY
tried without a problem, but want to know if it is a bad idea, and the reasons if any..
thanks
If you don't want to hit the database each time you'll have to cache the model. There are several ways to do this, but one quick way is using Memoization. This was introduced in Rails 2.2.
class Category < ActiveRecord::Base
class << self
extend ActiveSupport::Memoizable
def named(name)
find_by_name(name)
end
memoize :named
end
end
Use it like this.
Category.named("some category") # hits the database
Category.named("some category") # doesn't hit the database
The cache should stay persistent across requests. You can reset the cache by passing true as the last parameter.
Category.named("some category", true) # force hitting the database
What do you want to do?
Maybe:
class Category
def self.some_category
Category.find_by_name("some category")
end
end
So you can call:
Category.some_category
=> <Category#2....>
It's not a terrible idea, but it's not really a good one either. It doesn't really fall in line with the way Rails does things. For one thing, you'll end up with a lot of ugly constant code. Too many ALL_CAPS_WORDS and your Ruby starts to look like C++. Bleah.
For another, it's inflexible. Are you going to make one of these constants for every category? If you add a new category two months from now, will you remember to update your Rails code, add a new constant, redeploy it and restart your server?
If it's important to you to be able to access categories very easily, and not repeat DB queries, here's a bit of metaprogramming that'll automatically look them up and create static methods like Lichtamberg's for you on first access:
def self.method_missing(category, *args) # The 'self' makes this a class method
#categories ||= {}
if (#categories[category] = find_by_name(category.to_s))
class_eval "def self.#{category.to_s}; #categories[#{category}]; end"
return #categories[category]
end
super
end
With this method in place, whenever you first call Category.ham, it'll create a class method that returns the value of find_by_name("ham") -- so that neither the query nor method_missing() runs again the next time you call it. This is pretty much the way the OpenStruct class works, BTW; look it up in the Pickaxe book if you want to learn more.
(Of course you'll still have the risk that, because these are all memoized, your Rails app won't reflect any changes you make to your category objects. This makes the assumption that changes won't happen or don't really matter. It's up to you to determine whether that assumption is valid for your app. You could always put an after_update callback in your code that resets ##categories if that's a problem; but at that point this starts to get complicated.)
I've got a legacy database with a bunch of idiotically named columns like:
some_field_c
some_other_field_c
a_third_field_c
I would very much like to make a Rails ActiveRecord sub-class that automatically aliases these attributes to their name minus the underscore and "c". However, when I tried:
attributes.each_key do | key |
name = key
alias_attribute key.to_sym, key[0, (key.length -2)].to_sym if key =~ /_c$/
end
in my class definition I got an "undefined local variable or method `attributes'" error. I also tried overwriting these methods:
method_missing
respond_to?
but I kept getting errors with that route too.
So my question (actually questions) is/are:
Is what I'm trying to do even possible?
If so, what's the best way to do it (iterative aliasing or overwriting method missing)?
If it's not too much trouble, a very brief code sample of how to do #2 would be awesome.
Thanks in advance for any answers this post receives.
Your problem is probably that attributes is an instance method and you're doing this in the context of the class. The class method that's closest to what you want is column_names.
you could do something like:
methods.each do |method|
if method.ends_with("_c") then
self.send(:defind_method,method.slice(0,-2)){self.send(method)}
end
end
Hmm... I cooked up this little solution that I thought ended up pretty elegantly...
Not sure if this will work, but I aliased method_missing to still allow active_record to do it's thang:
module ShittyDatabaseMethods
alias :old_method_missing :method_missing
def method_missing(method)
if methods.include?("#{method}_c")
send("#{method}_c".to_sym)
else
old_method_missing(method)
end
end
end
class Test
attr_accessor :test_c
include ShittyDatabaseMethods
end
You may not get to name your module "ShittyDatabaseMethods", but you get the idea ;) Once you define that module and stuff it into lib, you just need to include this module and off you go :D
Would love to hear if this works out for you :)