Here is the scenario: I am building a system that will let users search for each other based on their skill sets.
Users have skills. Skills are universal objects and are shared amongst users.
Users have the following metadata associated with skills: level and interest
Each user can create their own categories under which they can organize their skills (e.g. one user might have the skill "Saas" under "Front-End Development" and another under "Web Development")
I have 4 tables: Users, Skills, Categories & Skillsets
Assuming that John Doe (username: "johndoe") has the following categories and skill set:
Category: Front-End
Skills: HAML, SASS/SCSS, CoffeeScript, Javascript, jQuery
Category: Back-End
Skills: Ruby, Ruby on Rails, node.js
I'd like to be able to perform the following operations:
user = User.where(:username => "johndoe").first
user.categories
# returns a list of the user's categories
user.skills
# returns a list of the user's skills
user.category.where(name => "Front-End").first.skills
# => returns list of skills in the "Front-End" category
user.skills.where(:name => "HAML").first.category
# returns "Front-End" category
# adds a skill without assigning it to a category
user.skills << skill_object
user.skills.last.level = 9
user.skills.last.interest = 6
user.skills.last.save
# adds a skill while assigning it to a category
user.category.skills << skill_object
user.category.skills.last.level = 9
user.category.skills.last.interest = 6
user.category.skills.last.save
And in order to find users by skill:
skill = Skill.where(:name => "Javascript").first
skill.users
# returns users possessing skill
I've been playing around with my models for a while but not quite getting to behave as I'd like them to. I need a fresh perspective - Any pointers / suggestions?
I know nothing about Ruby, but from a relational db perspective, I'd probably just create a special, hardcoded, category field for each user: Uncategorized.
Then, when you add skills, they either go in a specified cateogory, or the default uncategorized one for that user. Outside of that one "special" record for each user, everything else would work perfectly no matter which skill or category you're looking at, and you can leave all your constraints in place without having to worry about null values.
UserID, User
1, me
CategoryID, UserID, Category
1,1,Uncategorized
2,1,Web GUI
SkillID, Skill
1,Javascript
2,Knitting
SkillID, CategoryID, Level, Interest
1,2,10,75
2,1,50,1
Depending on how you use Level and Interest, I'd also consider making them lookup tables to give meaning to the values from a database perspective (and help populate drop down lists).
etc.
Related
I'm developing an API in Rails in which exists users and messages tables. Also users have a gender (gender_id), belong to a country (country_id) and also have a civil status (civil_status_id) and the messages are created by admins.
So up to here I have this model.
Now I have to develop the following requirement
An admin should be able to create a message targeted to users depending on its attributes (country, gender or civil status). Also, the admin should be able to declare a message as a global message, in this case "all" users should receive it, but exceptions should also be allowed. For example, in the case where an admin want to send a message to users from all countries, except people from Russia and China.
The thing is I'm no Rails/SQL expert, but I want to make this efficiently so that if tomorrow the app has ten thousand or a hundred thousand users the server responds quickly.
So I was thinking the following
First create 3 many-to-many relationships (countries_messages, genders_messages and civil_statuses_messages). The record of these tables represent the relations between the messages and the countries, civil_statuses and genders.
Then create a form where an admin can create a message, where by means of several select boxes, he should be able to choose the attributes of the users to whom he wants to reach. The form for creating a message should also have a checkbox to determine if the message is global, if its marked then I would consider that the selected countries, genders and civil statuses would be the categories that the administrator wants to exclude, i.e. if an admin want to send a message to all the people in the system except for people who are from Canada he should mark the global option and select the country Canada in the select box (obviously this would be stated in the view).
Now up to here I have this model.
In what I do have doubts is which way is more efficient to return the messages that corresponds to a user.
Method 1
When an admin specifies that a message is global, except for those from country with id 3 then I could add to countries_messages records like (country_id: 1, message_id: 2), (country_id: 2, message_id: 2), (country_id: 4, message_id: 2), ..., etc. i.e. forming a relation with every country except the country with id 2.
Then retriveng the messages that the current user should read like the following:
global_messages = Message.where(global: true).ids
country_messages = current_user.country.messages.ids
gender_messages = current_user.gender.messages.ids
civil_status_messages = current_user.current_status.messages.ids
#messages = Message.find(global_messages + country_messages + gender_messages + civil_status_messages)
Method 2
Other way could be forming a relation of that message with the excluded country, i.e. if I make a message exclusively for people from country with id 2 then I should add the record (country_id: 2, message_id: 2) in countries_messages, but in the contrary case if I made a message to every country except the country with id 2 then I should also add the record (country_id: 2, message_id: 2) to countries_messages.
In this case I can know if a message is excluded for males and people from Argentina, for example, if the message is global AND it's associated with the country and gender record that represents Argentina and males.
Then the retriveng of the messages that the current user should read would be like this:
global_messages = Message.where(global: true).ids
country_messages = current_user.country.messages
gender_messages = current_user.gender.messages
civil_status_messages = current_user.current_status.messages
excluded_country_messages_ids = country_messages.where(global: true).ids
excluded_gender_messages_ids = gender_messages.where(global: true).ids
excluded_civil_status_messages_ids = civil_status_messages.where(global: true).ids
#messages = Message.find(global_messages + country_messages + gender_messages + civil_status_messages - excluded_country_messages_ids - excluded_gender_messages_ids - excluded_civil_status_messages_ids)
There could be more ways to do the same, so I want to receive recommendations or if you see that I could make improvements to do the same then tell me. If there is something you do not understand ask.
Depending on your database choice, you may want to consider storing the message "attributes" (country, gender, ...) in a jsonb column on your messages table. It could also include a user_ids attribute to simplify things. The queries might look a little funny, but you can move a lot into scopes to clear things up in your code and even add indexes to speed things up.
Here is a great article on using jsonb with indexes in Rails with postgresql.
Another alternative you could do is make a UserMessage join table with a polymorphic reference that could associate the different attributes to a message and user:
class UserMessage < ApplicationRecord
belongs_to :user
belongs_to :message
belongs_to :messageable_type # e.g. "Country"
belongs_to :messageable_id # e.g. some Country id
end
I'm using the AR includes method to execute a LEFT OUTER JOIN between objects User and Building, where a User may or may not have a Building association:
users = User.includes(:building).references(:buildings)
Since I'm using references, any associated Building objects will be eager loaded.
My expectation was that I would then be able to iterate through the list of users, and check whether a user had a building associated with them without triggering additional queries, but I see that in fact whenever I try to access the building property of a user that doesn't have one, AR makes another SQL call to try and retrieve that building (though on subsequent tries it will just return nil).
These queries are obviously redundant as the association would have been loaded during the initial join, and seems to defeat the whole purpose of eager loading with includes/references, as now I'm looking at N times the number of queries equal to the number of empty associations.
users.each do | user |
# This will trigger a new query when building is not present:
# SELECT "buildings".* FROM "buildings" WHERE "buildings"."address" = $1 LIMIT 1 [["address", "123 my street"]]
if user.building
puts 'User has building'
else
puts 'User has no building'
end
end
User class:
class User < ActiveRecord::Base
belongs_to :building, foreign_key: 'residence_id'
end
Is there a way to check the presence of the users' building association without triggering extra queries?
ON RAILS 4.2.0 / POSTGRES
UPDATE:
Thank you #BoraMa for putting together this test. Looks like we're getting different behavior across recent Rails versions:
OUTPUT (RAILS 4.2.0):
User 1 has building
User 2 has building
User 3 has no building
D, [2016-05-26T11:48:38.147316 #11910] DEBUG -- : Building Load (0.2ms) SELECT "buildings".* FROM "buildings" WHERE "buildings"."id" = $1 LIMIT 1 [["id", 123]]
User 4 has no building
OUTPUT (RAILS 4.2.6)
User 1 has building
User 2 has building
User 3 has no building
User 4 has no building
OUTPUT (RAILS 5.0.0)
User 1 has building
User 2 has building
User 3 has no building
User 4 has no building
Take aways:
This issue was limited to "dangling foreign keys (ie the residence_id
column is not nil but there is no corresponding building object)"
(THANKS #FrederickCheung)
The issue has been resolved as of Rails 4.2.6
Sounds like you got bit by a bug in Active Record, that was fixed in rails 4.2.3.
In the case where the column was nil Active Record already knows that it doesn't even need to try loading the associated object. The remaining cases were the ones impacted by this bug
Seems like a typo, please notice building instead of buildings: User.includes(:building).references(:buildings)
That should trigger the big query that uses the format of AS tX_rY for each association and table.
It seems that since rails 4.1 there are potential clashes with how just how implicit #includes should be, see the following open issue.
This code is all untested for syntax, but there would be two approaches I would try:
1/ Make the eager loading implicit
users = User.eager_load(:building).preload(:buildings)
2/ Separate out the two types of users, ones where the building is attached, meaning you don't even try and preload the building, removing the innefficiency.
users = User.includes(:building).where.not(residence_id: nil).references(:buildings)
users.each do | user|
puts "User has building: #{user} #{user.building}"
end
# No additional references needed to be eager-loaded.
users = User.where(residence_id: nil)
users.each do | user |
puts "#{User} has no building."
end
Let's say I have the following entities in my libraries app - Library Room, shelf, Book.
Where Room has N shelves, and shelves have N Books.
Now the following url brings me a list of books whose
library is 3, room no. is 5 and shelf no. is 43.
.../library/3/room/5/shelf/43/books
Assuming shelf 43 is unique per room only
(There is shelf 43 also in other rooms)
and Rooms are not unique (There's a few room no. 5 ) in the library.
Here is my questions:
I want to filter with more fields on the entities, here is what i want to do
(representation not in rest):
.../library/id=3&type=3/room/decade=21&topic=horror/shelf/location=east&/books
This is not rest.
How do I represent it in rest?
Notes:
I don't want to do this way
.../books¶m1=X¶m2=X¶m3=X¶m4=X
because not all params are related to books.
Couple of things that you need to look into while designing your apis.
1) are type, decade, topic etc required fields? if so, I will probably make them a part of the path itself, such as:
../libraries/{libraryId}/type/{typeId}/rooms/{roomId}/decades/{decadeId}/topics/{topicName}/shelves/{shelfId}/locations/{shelfLocation}/books
Here I am assuming that each library can have rooms which have unique room ids per library, each room can have shelves which has unique ids/locations per room (and so on and so forth). Yes, the url is pretty long, but that's kind of expected
2) if these fields are not required, you could use a different approach which is a bit less verbose but a bit more confusing for client developers who have never used such approach here. Here's a straight up example Restful Java with JAX-RS by Bill Burke
#Path("{first}-{last}")
#GET
#Produces("application/xml")
public StreamingOutput getCustomer(#PathParam("first") String firstName,
#PathParam("last") String lastName) {
...
}
Here, we have the URI path parameters {first} and {last}. If our HTTP request is
GET /customers/bill-burke, bill will be injected into the firstName parameter and
burke will be injected into the lastName parameter.
If we follow this somewhat academic approach (I have not seen this implemented on many platforms. Most platforms normally go with approach # 1, a more verbose but clear approach), your URL would look somewhat like this:
../libraries/{libraryId}-{typeId}/rooms/{roomId}-{decadeId}-{topicName}/shelves/{shelfId}-{shelfLocation}/books
This way, if the client developer doesn't pass in the non-required fields, you can handle it at the business logic level and assign these variables a default value, for example:
../libraries/3-/rooms/2-1-horror/shelves/1-/books
With this url, libraryId = 3, typeId = null (thus can be defaulted to it's default value) and so on and so forth. Remember that if libraryId is required field, then you might want to actually make it a part of the pathparam itself
Hope this helps!
I have a table Category that is a polymorphic model for a bunch of other models. For instance
model Address has shipping, billing,
home, work category
model Phone has home, mobile, work,
fax category
model Product has medical, it
equipment, automotive, aerospace, etc
categories.
What I want to be able to do is something like
Product.all_categories and get and array of all categories that are specific to this model.
Of course I can do something like this for each model in question:
Category.select("name").where("categorizable_type = ?","address")
Also pace_car - which is rails 3 ready, allows me to do something like this:
Category.for_category_type(Address)
But I was wondering if there is a more straightforward / elegant solution to this problem using Active Record iteself - without relying on a gem?
Thank you
I'm not aware of anything built-in to ActiveRecord to give you this, but you could set up that for_category_type method in one line of code in your Category controller:
scope :for_category_type, lambda { |class_name| where("categorizable_type = ?", class_name) }
I have an app where users have a role,a username,faculty and so on.When I'm looking for a list of users by their role or faculty or anything they have in common I can call (among others possible)
#users = User.find_by_role(params[:role]) #or
#users = User.find_by_shift(params[:shift])
So it keeps the system
Class.find_by_property
So the question is: What if at different points users lists should be generated based on different properties.I mean: I'm passing from different links
params[:role] or
params[:faculty] or
params[:department]
to my list action in my users controller.As I see it all has to be in that action,but which parameter should the search be made by?
Try https://github.com/ernie/meta_search if you're on Rails 3