No. Thats true in Rails world as rails there is a convention how you should define classes and file names. Rails uses this convention while loading the classes. A class named UserRegistration should reside inside a file named user_registration.rb. This is a standard convention that rails follows otherwise rails won’t be able to load the class.
Avoid using Rails models in migration.
- Models might have some
lifecycle callbackswhich we dont want to be invoked in a migration.
- As we know what we are doing we dont want to deal with
- Model names can change irrespective of db table.
- Try to use
raw sqlas close as possible.
Squash them after a period of time.
- To my experience over a period of time these migration files are painful and useless.
rake db:migratemight take a few seconds, or creating of a new database might take a few minutes when these files are big. Consider using tools like squasher.
Make them irreversible.
In Production it makes sense to have IrreversibleMigration as the code is tested in lower environments. If there is an issue try to fix it with a follow up migration.
Note: If there is a new developer in your team and setting up their environment. Let them do `rake db:schema:load` to get latest db copy.
I dont think i used
after_validation ever as
before_save(or similar callbacks like before_create or update) is the one which fits. Usually the flow is
before_save seems to be the last step in the process and by the time it reaches there the record is valid. Like you wanted it to happen every time when validation is successful.
after_validation is called irrespective of the validation failed or not. I cant think of a scenario where you want to use it.
We cannot substitute
before_save as we can not guarantee that the record is always going to be valid.
There is no hard and fast rule. But i am putting out when to use what based on my experience.
- you are in a big team working on a feature branch and you want to rebased from master. If you dont have all the commits you are in trouble.
- When you find rebasing is becoming painful for no reason. like for every rebase step you need to fix the same lines of code again and again.
- Not worried about one more additional commit and order of commits as they are going to be mixed up.
- you dont want to change the commit history/log.
- You want the commit history looks clean. As new work will be on top of everything.
- when you have less code changes or you know how to deal with conflicts (more patience required practice meditation).
- you branched off of feature branch to your own branch. You can do what ever you want as its your world.
If you have encountered this error and wondering how to fix it this post is for you.
Rails raises this error when it tries to eager load a polymorphic association using a JOIN.
For example i have a
Booking which belongs_to polymorphic association
order. An Order can be a
class Booking < ApplicationRecord belongs_to :order, polymorphic: true end
class PickupOrder < ApplicationRecord has_many :bookings, as: :order, dependent: :destroy, inverse_of: :order end
class DeliveryOrder < ApplicationRecord has_many :bookings, as: :order, dependent: :destroy, inverse_of: :order end
I can load all bookings along with orders like this
Now if I want to search list of bookings by `order_name` like `ja`
Booking.includes(:order).references(:order).where("order.order_name ilike %ja%")
Throws the error
ActiveRecord::EagerLoadPolymorphicError: Cannot eagerly load the polymorphic association :order
Solution: Do it in sql. with left outer joins.
Booking.joins("left outer join delivery_orders on delivery_orders.id = bookings.order_id and bookings.order_type='DeliveryOrder'"). joins("left outer join pickup_orders on pickup_orders.id = bookings.order_id and bookings.order_type='PickupOrder'"). where("pickup_orders.order_name like '%ja%' or delivery_orders.order_name like '%ja%'")
Have you ever encountered this error while working on
`DEPRECATION WARNING: In XXX class you exposed a `has_one` relationship using the `belongs_to` class method. We think `has_one` is more appropriate. If you know what you’re doing, and don’t want to see this warning again, override the `belongs_to` class method on your resource.
If yes this post is for you. Dont break your heads its on `jsonapi-resources`.
It looks like jsoapi-resources did not implement the `belongs_to` as how it should be. At least as of this writing (0.9.0v). It treats `belongs_to` and `has_one` relations in the way. here is the source which points to this. So for time being change your `belongs_to` to `has_one` and you are gold. Happy coding!
There are two things to consider to select a good pineapple.
- Smell : If you are able to get the sweet smell of pineapple then it is the right one.
- Ripened : Try to pluck one of the leaves on top of it. If you can get them without much effort that says it is ripened.
I dont believe in color as it may be deceiving. With smell and ripeness i am always successful in getting a sweet pineapple. Happy shopping.