In rails/activerecord, is it possible to have three ruby classes, two of which inherit from one main class, and then have two separate tables for pots and pans. Like so...
class Tupperware < ActiveRecord::Base
end
class Pot < Tupperware
end
class Pan < Tupperware
end
and the advantage would be that I could use the Tupperware.find() method, and a few other things, without having to customize for each different type.
I know for sure it works with mongoid – I've done it myself a couple of times. I'm not sure if this would work in relative database engine...
But you're actually asking a question you could answer yourself, by just trying to do what you said.
[In response to OP's comment]:
I'm just saying you should do a test rails application using a relative db, such as mySQL or SQLite and define your models exactly the way you think.
I have an abstract model I use in my application. It's working perfectly and the find() method works just as you'd expect, but I'm working on Mongoid, so I don't use ActiveResource and can't say for sure if this will work for you. The only thing you can do is try.
Here, take a look at this excerpt from my code:
https://gist.github.com/ellmo/5262681
Related
Sometimes putting a "barrier" between classes can be very helpful in the long run (although it seems a problem at the beginning). For example, in Rails models are not able to call the controller or the views. This helps having clean/testable/flexible code. Is there a name for this?
For example, when all the classes have references to other classes and are able to send messages to them, you end with code that is coupled.
I am currently going through Hartl's Rails Tutorial, and through the first 10 chapters or so have gotten used to the convention of putting most of the actions/methods in the controller. Currently, as the book is going through and defining a feed method for the Microposts, the method is placed with the User.rb model instead. As I am relatively new to the world of rails (and programming in general), I was wondering what the rationale or convention followed for putting this method (copied below) in the Model?
The method placed in the User.rb model:
def feed
# This is preliminary. See "Following users" for the full implementation.
Micropost.where("user_id = ?", id)
end
There is actually quite some contention on what code to put where, but in general, there are some easy guidelines to follow.
Does the method have to know some detail about the underlying data structure? Put it in the model.
An easy way to determine this is when it uses ActiveRecord methods like find, where, or specific columns in the database. By keeping this logic in the model, that means if you need to change the underlying datastore, you only have to change the model.
Does the method have some say in how a page is going to be rendered? Put it in the controller.
Generally, controllers should be pretty thin, pushing data to views and saving form data back to models.
While (if I remember correctly) Hartl does not take about non-rails classes, don't be afraid to put 'business logic' outside of the rails structure. You can create a app/lib or app/services or app/x directory and put plain old ruby objects in there, which can then be called from your controllers and models to handle those things they are good at.
Aim to 'push' things 'up' into the model as much as possible, then they will be repeated less and available to more. Don't just use models for Active Record database tables.
You can often unit test models easier.
Another 'next' place to put stuff that is shared is in /lib
Just started using factory girl. If one has to save a factory into the db then one has to run
FactoryGirl.create().
But is there any way to load a collection of factories into the database without having to call create on each of the factories?
If its of any help i'm using Ruby 1.9.3, Rails 3.2.8 and Factory Girl 4.1.
If you need a bunch of factories of different type, you'll simply have to create them individually. You can make this a bit less verbose by adding this to your test_helper.rb:
include FactoryGirl::Syntax::Methods
Then you can create factories like this:
create(:factory_name)
And of course, if you need a bunch of records of the same type, you can create them like this:
5.times { create(:factory_name) }
As mentioned in my comment, creating all your factories in one fell swoop on initialization of your test framework is counter-productive. The idea behind FactoryGirl is to provide just the data you need for each test case or context. This avoids dependencies between tests that tend to slip into a fixture-driven approach.
In Ruby on Rails 3, I can't scaffold a model called Data. I can make the Data controller but I can't make the Data model. It has to be UserData or something along those lines.
Ruby on Rails says, it is being used already (my guess is) by the gem itself.
Am I the only one getting this?
How come I cannot create the model name to be Data only?
I think your problem is that there is already a Data class in the Ruby standard library (both 1.9+ and 1.8.7). The Data class is only defined in one of the C source files but it is still publicly visible. I'm not sure what the Data class is for (and the documentation is rather sparse) but the name is already in use so Rails won't let you use it. You can make the controller easily enough because the controller will be DataController and that name isn't taken.
I need perform some extra logic on an object before it is saved to the database. I would assume that using a before_filter would be the correct way to accomplish this, but I'm not sure how to pass the object to be saved into my before_filter method.
This is my first ever post here so go easy on me!
Theres a before_save method, in Rails 3 at least, that can be called in the model.
in Posts model
before_save :add_url_and_ID
def add_url_and_ID
#extra logic
self[:url] = whatever.com
self[:member_id] = member.id
end
I'm probably way off but its my first go!
That all sounds like model code to me. To get the most out of Rails (or any MVC framework) follow the 'Fat Models, Skinny Controllers' rule of thumb. It can be taken too far, but I think in this case it's pretty clear. If there are errors with the helper functions you mention, shouldn't the save action fail with appropriate error messages?
There's lots of good posts on SO on this subject. Here's one
If this doesn't give you enough to work with I'd suggest posting some code.