I am trying to learn to model SQL databases, and am having some trouble understanding some concepts. I want to a build an app, where users can split a bill at a restaurant. Could someone please tell me if the following is allowed?
I have Bills, Items, and Users
Bill has_many :items, dependent: :destroy
Bill has_many :users, foreign_key: :user_id
User has_many :bills, foreign_key: :created_by
Item belongs_to :bill
Is it ok for a user to have many bills, and a bill to have many users?
This is a more fundamental database design issue. If I were to design this database for a bill sharing app, it would be like this
user.rb
has_many :bill_contributions
has_many :bills, through: :bill_contributions
bill.rb
has_many :items
has_many :bill_contributions
has_many :users, through: :bill_contributions
bill_contribution.rb
belongs_to :user
belongs_to :bill
I split it like this because there is a has many and belongs to many relationship between the user and bills as a user can have a lot of bills and bills can be split among many users. you can look up HABTM
database relationships if you wish to learn more
Related
in a Rails 3 application there are two models assinged to each other by belongs_to and has_one. On both sides there is :depended => :destroy configured for this association.
now I had to add a :before_destroy callback in one of these models. the problem is now that this callback is triggered twice when an entity which includes this callback is destroyed. When I remove :depended => :destroy in the other model, it's triggered only once. So it seems this i causing the problem.
is there an elegant way to fix this ?
:dependent
Controls what happens to the associated objects when their owner is destroyed
dependent destroy must be alone in a model
has_many :comments, dependent: :destroy
has_one :position, dependent: :destroy
Sorry for my english XD
i have an application am designing which consists of users making friends and users
having many posts, paintings, friends and talks
the model is below
class User < ActiveRecord::Base
has_many :paintings, :dependent => :destroy
has_many :sells, :dependent => :destroy
has_many :posts, :dependent => :destroy
has_many :talks, :dependent => :destroy
has_many :friends
has_many :comments
end
i have set a notification system in which when a user creates a post or painting e.t.c
a notification is sent to the users friends which i have achieved with public_activity gem,
what i intend to achieve is a notification system in which when the notification is created, every user involved can mark as seen i.e they have seen it so THAT notification is not shown to the user anymore... And also when a user comments on a notification, i want a notification to be sent to the owner of the activity, and any other user that comments on THAT notification... IN SUMMARY, I NEED A FACEBOOK LIKE NOTIFACATION SYSTEM...
Have you considered creating a Notification after the relevant post/painting has been added?
Notifications would be created (probably using an after_create action on each of the relevant models e.g. posts, paintings).
class Post < ActiveRecord::Base
after_create :create_notification
private
def create_notification
# create notification here
end
end
If there are lots of notifications to be created then you may wish to consider creating them in a background job.
A notification would belong to the target friend of the user and could therefore be marked as seen through an attribute on the notification. You would include instance methods on the notification object to deal with this.
class Notification < ActiveRecord::Base
belongs_to :user # friend of the originating user
def mark_seen
update_attributes(viewed: true)
end
end
You could also add scopes on the notifications to make sure that users can easily see unseen notifications.
class User < ActiveRecord::Base
has_many :notifications
has_many :unseen_notifications, conditions: "notifications.viewed IS false" #or something like that
end
Hope this helps to set you on the right track.
I am trying to write a database for a company in town. I am using Devise for authentication, and Forem for the forums of the site. I decided to just have one class, "Account" for the Devise authentication, which will have many different access types to the site.
The bulk of the users will be just customers, which are segregated by routes (not Rails routes, street routes). So I decided to have them have their own profile model.
I want to do this - Profile is linked to account, and to route. (Routes are named gmr_routes)
Is this code the proper way to do it? Documentation I've found hasn't told me I can't, but I just want to be sure....
class Profile < ActiveRecord::Base
attr_accessible :first_name, :last_name, :phone_number, :street_address
belongs_to :account
belongs_to :gmr_route
end
Account has a has_one relationship with Profile, and gmr_route has a has_many.
Is this right?
Bryan
Yes, that's perfectly acceptable. You need to remember to include a foreign key id on any model with a belongs_to.
So in the case you describe, you would have account_id:integer and gmr_route_id:integer in your migration, and include those in the attr_accessible call in your model
I am designing a website which has many users, each user has many posts, and each post has many photos. Because I hope user can preview the upload photos when they are creating new post, I found the answer here, which suggested using a subform to upload photos.
I use carrierwaves to handle photo upload, and jquery-file-upload for user interface. The models are:
class User < ActiveRecord::Base
has_many :posts, dependent: :destroy
end
class Post < ActiveRecord::Base
attr_accessible :title, :description, :photo_ids
belongs_to :user
has_many :photos, :dependent => :destroy
end
class Photo < ActiveRecord::Base
mount_uploader :image, ImageUploader
attr_accessible :image
belongs_to :post
end
In the new post view, I put a jquery-file-upload UI above the normal post form, then:
When user select a photo, it will be uploaded to PhotosController via jquery-file-upload api. The post_id for this photo is nil at this step.
After photo uploaded finished, I use javascript to add a hidden input form like this:
input type="hidden" id="collection_image_ids" name="collection[collection_image_ids][]" value=#{the id of the photo}
User can repeat step 1&2 many times, then submit the post.
Everything works well, however....
I don't think it's a good idea to allow mass assignment for photo_ids because someone can use this request to assign other user's photo to his post. (in edit view)
The reference answer suggested using some randomized access key to improve the security,
but when someone visit other user's post, he can still get the randomized access key of those photos, right?
So the implementation is not safe for now right?
Could anyone give me some suggestions or what is the proper way to handle this problem?
I am working on a project (Rails 3.0.3) where I think I may need to use STI, but I am not sure if I should just add an extra column to a table and be done with it.
In my object model, (for a gaming system) I have players (who belong to agencies) and owners (who own the agencies).
Both players and owners are owned by agents, which is a user account, so an agent can be a player and/or owner in many agencies.
I should have named agent 'user' instead, oops. So I have this:
class Agency < ActiveRecord::Base
has_many :players, :class_name => "Player", :foreign_key => "agency_id"
has_many :agents, :through => :players, :source => :agent_id
has_one :owner, :class_name => "Owner", :foreign_key => "agency_id"
end
class Player < ActiveRecord::Base
belongs_to :agency, :class_name => "Agency", :foreign_key => "agency_id"
belongs_to :agent, :class_name => "Agent", :foreign_key => "agent_id"
end
class Owner < ActiveRecord::Base
belongs_to :agency, :class_name => "Agency", :foreign_key => "agency_id"
belongs_to :agent, :class_name => "Agent", :foreign_key => "agent_id"
end
Player and Owner both share exactly the same attributes, the only difference between the two is that Owner has a different relationship with Agency than Player does (the Owner owns the Agency, the Agency only has one Owner, but has many players).
Additionally, the Owner is given special rights, such as the ability to adjust the settings in an agency.
From a pure OOP perspective, Owner is a subclass of Player (or, Owner and Player are both subclasses of some undefined class like Participant or something), but when accounting for persistence, it seems like poor database design to have separate players and owners tables.
My first thought was to refactor and employ STI and either make Owner a subclass of Player or introduce a new base class and then subclass both Owner and Player.
My other thought was that I could just add a boolean/tinyint column to Player called is_owner, but I can forsee that potentially leading to some nasty view and controller code.
I was wondering if anyone out there has run into a similar circumstance and maybe has any advice or could point me to some good online resources to read up on STI?
Maybe you should think of Player and Owner as relations between Agent and Agency. So an Agent owns an Agency and an Agent plays games of an Agency. Hence you might introduce the concept of a role and hence a model Role from which Player and Owner inherit. The question is: Do you ever want to use the Role model? Or is your application about owners and players and except of some common attributes they are two totally different kind of things?
If they are two different things, then you should make them two different models. If you have some code duplication between the two models, then you might use a (or multiple) mixin(s) to share code between them.
In general I prefer composition over inheritance. In the first place inheritance looks like an elegant way to share code between classes but it isn't about that. Inheritance is about types and interfaces. Hence you couple things in terms of their interfaces. This is strong constraint in the further development of your models.
I use inheritance only if there is real is_a relation and not a shares_some_code_with relation between to classes. And more important: I use it if and only if it has an technical advantage for me. Otherwise there are much better ways to share code between classes in ruby.