I'm probably asking for the wrong thing. What I'd like is a model which extends the class ActiveMerchant::Shipping::Location, but is also saved in the database and has other neat active record associations like multiple employees, working day schedules, etc.
I know I can't inherit from multiple classes- what's the best way to create a Location class with both ActiveMerchant::Shipping::Location properties & methods and additional ActiveRecord properties & associations?
You can inherit from ActiveMerchant::Shipping::Location and include ActiveModel::Model and/or other ActiveRecord modules you desire.
Related
Say I have Single Table Inheritance with BuyerInvoice inheriting from Invoice.
If I assign such an invoice to a polymorphic association, Rails will store e.g. record_type: "Invoice" rather than record_type: "BuyerInvoice". It stores record.class.base_class.name.
What are some reasons they may have done this? I'm implementing something vaguely similar and would like to understand why Rails might have made that decision.
Best I can think of is that it makes it a bit easier to rename subclasses without affecting associations, though doing it the other way would make it easier to rename abstract superclasses…
STI is an implementation detail of a model, it should not leak into its relations.
Other than renaming subclasses:
STI can be implemented with custom class resolution (with type column not being a class name at all), even have some weird cases where class changes dynamically based on attributes etc.
STI can be added to a model after it already has relations
STI can be removed at all
I have a model called Client.
This extends not from ActiveRecord::Base but from my own wrapper class.
These objects are not stored in my own database.
I have some other models called Answer and Device for example. These are stored in my database with a client_id.
Now, what I want to do is that is can call Answer.client and Client.answers for example. The normal way would be with ActiveRecord associations but that doesn't work is this case.
I can define my own .answers and .client method but in my opinion that's not the way to go with Rails.
Thanks in advance for replying!
Is there a specific naming convention for a model that will not be stored in the database? For example, i have a schedule which will be a model, but will not be in the database because it is just a data structure. In other words it will not extend ActiveRecord::Base?
I view this as an internal implementation detail; I wouldn't reflect it in the name, because other models that are interacting with a given model should not know or care whether it is persisted. And your requirements could change later and it would become persisted.
If you want to create a class in the Model that doesn't persist to the database than just don't inherit ActiveRecord::Base
e.g
class SomeClass
end
The class definition is still saved to the file some_class.rb in the model directory
As for naming convention. Well a Model class is a Model class, it doesn't matter if it persists to the database, or some place else, or not at all. I see no need for any special naming convention.
Your Controller and Views should just interact with the your Model objects without being concerned about that object's underlying persistence mechanism. That's one of the main advantages of Model-View-Controller ... The Controller and View need not be concerned with the inner working on the Model objects. So neither should your naming convention.
I tend to make non-active record models to inherit from the NonActiveRecordModel class (or something like that, which you can define yourself). The abstract NonActiveRecordModel class can have common behavior that is used by all of your non-active record models, such as validations via validatable gem, etc.
I have a Record model (Active Record) that stores some custom logs.
Record is in polymorphic association with all the other model in my app, and I can effectively log what I want hooking my Record methods in the other controllers.
What I need:
To have the logs in a separate database.
So I have to:
Be able to manage two different databases in my apllication (one is Postgres/ActiveRecord and the other one is MongoDB/MongoMapper)
Generate a polymorphic association between my Record model, now with MongoMapper, and the rest of my Active Record models.
That way I can persist my logs to the MongoDB database.
Thanks.
Yes this can be done.
To create a polymorphic association you need both the class and an id. Idiomatically the fields will be named <assoc>_type and <assoc>_id‡. You will need to do some wiring up to make everything work.
Create a MongoMapper::Document Class with the keys <assoc>_type and <assoc>_id with the correct types (I believe MongoMapper allows Class as a key type) along with any other keys you may need.
Define the method <assoc> and <assoc>=
def assoc
assoc_type.find(assoc_id)
end
def assoc=(input)
assoc_type = input.class #STI makes this more complicated we must store the base class
asspc_id = input.id
end
Possibly add a method to your ActiveRecord models allowing them to access you MongoMapper logging class. If there are a lot, you may want to build a module and include it in all the classes that need that kind of functionality.
‡ replace with something meaningful for you application like 'reference' or 'subject'
I have just started investigating using more advanced models in Rails. One that I use regularly, with great success, is model where a many-to-many cross-reference relationship is accessed by a class that itself is a sub-class of the base class in the many-to-many relationship.
This way the cross-reference class can act as a stand-in for the base class.
A good example is where a navigation hierarchy node (NavigationNode) is cross-referenced to a user role. At the cross-reference point a class (RoleNavigationNode) can inherit from NavigationNode and still have intimate knowledge of the user role.
My question is (in the case above) can RoleNavigationNode inherit from NavigationNode and yet access the cross-reference table rather than the one that NavigationNode accesses -- this of course using ActiveRecord.
I have not investigated polymorphic association, which may be more appropriate.
Thanks in advance...,
tried set_table_name on the subclass?
Also, look into setting #abstract_class in model classes.
Lastly, what you need may simply be a Mixin that you include in both models.
Anyway, what you're trying to do sounds rather un-ActiveRecord-ish. You might want to post a clearer example of what you're trying to achieve, maybe we'll be able to come up with something simpler.
This works in Rails 3:
class Common < ActiveRecord::Base
#abstract_class = true
def common
"Foobar!"
end
end
class Model < Common
end
class AnotherModel < Common
end
Without setting abstract_class, Rails will look for a table named commons in your database.