I'm about to add a model to my app and I was inclined to call it "collection". It was also to have a field called "status" but it occurred to me that I think Rails uses both those terms elsewhere and this might be a problem worth avoiding.
Should I pick another model name instead of collection? and would state be better than status?
Thanks.
I've used both before - I think you should use whatever makes most sense to you, that aren't reserved words. If you think they will conflict with logic elsewhere in your app, then you might consider a different model name and/or column name.
Related
I have a model StockEntry which belongs to a stock_logable for ex: InvoiceItem, ReturnItem etc. My model looks something like this:
belongs_to :stock_logable, polymorphic: true, optional: true
Now I need to handle the case of opening stock. This is how i handled it:
id: 1
stock_logable_type: "Opening Stock",
stock_logable_id: nil
quantity: 10
So basically I left the stock_logable_id blank and stock_logable_type a string. I don't have any model such as "OpeningStock" in my application.
Even though this works perfectly but i am still unsure whether this is a good way to handle the concerned scenario. Any insights/feedbacks will be helpful. Thanks
I don't know your business domain, but I'd rather create an OpeningStock model and set stock_logable to it. Setting polymorphic type without id may lead to nasty errors.
You can also do STI in StockEntries and keep there opening stock then. Or even without any inheritance - you can add state to the StockEntry to mark if it's opening or regular.
I am guessing you create the StockEntry first, and no "logable" (I personally prefer "loggable") is available/linked yet, and this is a special state called "opening stock", correct? You now seem to use the stock_logable_type to reflect this state. This is either because you also have StockEntry without a stock_logable for a different reason or to make your code/data more self-explanatory?
So if there are other states, I would create an actual state (use an enum or link to a domain table), but otherwise I would just leave the stock_logable unassigned completely, and maybe add a convenience method
def opening_stock?
stock_logable.blank?
end
to make your code more readable.
I know type is a magic field name with ActiveRecord for use in Single Table Inheritance. But :type is not included in Mongoid.destructive_fields. Is there any reason I can't use it as a field name? Upload.upload_type feels so ackward and I'd much prefer to use Upload.type.
Furthermore class, category, and variety don't seem like good alternatives.
I am using it without any problems so far. So unless I run into any issues down the road I'm going to answer no, there's no reason to avoid using the word "type".
In Mongoid an attribute _type is define to help in the STI too. So it's better to avoid using it too.
You are correct that "_type" is used for STI and thus "type" is technically a valid attribute name. It will work for your situation just fine. I would just be cautious using those "special names", however. If you ever switch over to a different database you will probably run into problems, but if you have control over that and know that you'll be using MongoDB, then there isn't a really good reason why you can't use the "type" field.
I personally would not use any of the special words that many databases or frameworks use, as it just makes it less-confusing for others. But that is just a personal preference; there's no technical reason.
I'm writing a rails application, and I need to name one of my model Test, and inside that model I need a class attribute - when I tried the first one, I couldn't run any UT since Test ceased to be a module - so I ranamed to Tst. I haven't even tried naming a column class - I went with clss. What names would you use? Are there any conventions known amongs RoR developers for such situations?
I haven't seen anything for Test but class is typically changed to klass.
Ruby and Rails have several different objects part of a standard library. You cannot use an already-defined class name as name for your models.
For instance, you cannot call a model Thread or Object because Ruby already defines a Thread and Object class.
Likewise, Ruby has a library called Test::Unit so you can't use the Test namespace as model name.
There isn't a real full list of reserve objects because it really depends on your current environment. However, in order to successfully use Rails, you should at least have a basic Ruby knowledge so that you know the names of the most common standard library classes.
I've run up against this a few times (writing educational software--where you regularly want to model 'tests' :-). Depends exactly what you're modeling I suppose, but I usually opt for 'quiz' to avoid conflicts. I'd love to hear a better solution, since I find 'quizzes' an awkward plural.
Like dj2 said, class is usually done as 'klass'.
Please check the following page for Rails reserved words: http://reservedwords.herokuapp.com/ None of these words should be used as class or attribute name.
Not sure what the difference between underscore (student_state) and tableize (student_states), other than tableize also pluralizes. However, not sure how they can be used
differently. Obviously, you can use tableize to reference table name in
database. But what different functionality does underscore provide, such as when you see :student_state compared to :student_states when used as symbols. Thanks for suggestions.
tableize will pluralize your string whether the original was singular or plural, while underscore will only add underlines.
While this may seem trivial, it's all about abstracting the details of database implementation away from the developer. If, down the road, Rails began formatting table names differently, the only method that would need to change would be tableize. All other places in the Rails code that refer to table names can stay the same, because they're still calling the tableize method. A change to the underlying structure of rails is therefore limited and much less damaging.
This is referred to as "orthoganality" in computer science. Now that you know what it means, try to throw it around in conversation to make yourself look smarter. Did it work for me? :)
I have a model by the name Filter but due to the changes in reorganizing the filters from 2.0.3, it is conflicting with the
ActionController::Filters::Filter (class)
In my filters_controller.rb when I try to find the filter
Filter.find(:id)
as rails is infering the ActionController::Filters::Filter class rather than my model class Filter. Is there any work around other than renaming my model?
BTW: If I use ActiveRecord::Base::Filter.find(:id) to load my filter object, its working, but I am not quite sure if there are any unforseen implications by doing this, when rails try to unload/reload constants.
Thanks in advance.
The safest way to deal with this is to rename your model. Otherwise you run the risk of being 'clever' and getting bitten by this later when it will be very difficult to debug.
I almost missed your comment, so to answer your own question.
::Filter.find()