I use acts-as-taggable-on https://github.com/mbleigh/acts-as-taggable-on for tagging user's post, I want to find one user's all post' all tags and list them, Is there a high performance method ?
You need to add acts_as_tagger to the User model
refer to https://github.com/mbleigh/acts-as-taggable-on#tag-ownership
then you can use the methods provided. If you're starting from a blank db, this should work but may need to run through some re-assigning loop to have the tagger association work.
Assuming your data is correct, you will then be able to do:
#some_user.owned_taggings
#some_user.owned_tags
Hope this helps
Related
With the ActsAsTaggableOn gem I would like to retrieve the most used tags used for posts by a certain user. Currently I have a user.rb model and a post.rb model which belongs_to the user. What I can do is this:
ActsAsTaggableOn::Tag.most_used
Which does show me the most used tags used overall. However, I would like to filter that down to only show me the most used tags by the current_user. I was thinking of something like:
ActsAsTaggableOn::Tag.most_used.joins(:posts).where(user_id: current_user.id)
which does not work since there is no connection established and therefore i cant join the models. How can I access the most used tags in the posts by the current_user?
ActsAsTaggableOn::Tag.joins(:taggable).where(taggable: current_user.posts).distinct.most_used(5)
After tinkering around with a lot of queries I got the solution now which might be a bit tricky.
Basically what ActsAsTaggableOn does is just assigning tags to the respective model. The tags however are in no way really related to anything else. What is possible is to assign tag ownership.
What I do now could be considered as bad practice: First the Post is assigned a tag which is stored in the tag_list, then I am going to trigger an after save action inside the posts.rb which grabs the last tag of the post object (only one tag can be assigned in my app) and assigns it to the user via
#user.tag(#post, with: "Some tag", on: :posts)
It would have been way easier to just code the whole thing myself and not rely on a gem, but its okay for now.
I am using rails 3.2.7, mongoid 3, and i am trying to use devise for users accounts.
Before i'll start: i was searching a lot for my problem, and i read many tutorials, byt none fit to my need.
I have similar problem like devise and multiple “user” models
but i am using mongodb so i think the problem is not exacly the same.
I have 3 types of users":
Manger which can have many places and can manage them(edit info).
User which can search for places(even no user can) and create their places lists. Also user can comment and note the places.
Administrator who can edit/delete anythig, so admin is a god.
So, all of them have different data(except of login info) and i don't know what solution is the best.
STI would be good if they would have the same data, and different actions, but data are different too(but i am using mongoid, so maybe it would be fine?)
Single user model with roles is another solution but i don't know how to store different data, maybe with polymorphic? I don't fully understand how it should be implemented with devise and maybe cancan.
Maybe there is third?
I know what is STI, polymorphic associations, also how to implement roles with CanCan, but the problem is that i dont't know how to connect them with devise?
If there would be few sign in forms or one, it doesn't matter. I don't have to use devise either.
I found few tutorials/examples how to use devise, monogid, roles for multi-users applications, but they are when users store the same data, so they don't fit for me.
Can you give me advice, or a maybe a link which could help me?
Thanks for help :)
I would recommend building different controllers for different use cases. Don't build dependencies of different views inside the data. This way you are free to use the data for other use cases or other user groups without changing it directly.
Simply create controllers for the different use cases. This way you can change them any time without changing your data model.
So, I'm trying to pull all photos of a specific user's account via the flickr.photos.search method, but I want to exclude photos with a particular tag. The related documentation page states that "You can exclude results that match a term by prepending it with a - character." ... Well, I tried implementing that option but what get in return is only one photo (even though there are several photos with the tag in question) and that result remains the same whether that specific photo has the tag in question or not AND whether or not I use the "-" option to exclude that tag rather than include it. I also tried the text method with the same exact result. Here's my REST call:
http://api.flickr.com/services/rest/?&method=flickr.photos.search&api_key='.$api_key.'&user_id='.$user_id.'&tag_mode=any&tags=-blog&extras=url_o,url_t&format=json
And here is the page where I'm trying to get this all working:
http://corazonbrew.com/temp/
Anyone know what is going on here?
It seems the answer in the Flickr discussion board I linked to earlier is proving true. In order to use the exclusion option, there has to also be at least one other, non-excluded tag. Well, that is just not good enough for me.
A couple of friends tell me this is a longstanding bug that will not be fixed anytime soon, if ever. But those friends also kindly reminded me of my n00bishness- this whole time I thought I needed to affect the feed to get the desired output. I totally was not realizing I could just use some good ol' PHP if statements to weed out what I don't want.
Back-end: I have a model (User) that has_many of another model (ContactPreference).
Front-end: An interface allowing the user to reorder, add, and delete contact preferences for a particular user.
I'd like to let the user commit all their changes all at once with a single form submit. The way I'm doing this now is with allows_nested_attributes_for :contact_preferences in the User model, and naively POSTing the attributes of the edited preferences list. It works just fine except for a glaring bug: If a user deletes a contact preference, the ID simply isn't sent, and the preference doesn't get deleted from the DB.
allows_nested_attributes_for has support for deleting objects from the collection, but it requires the client to keep track of what IDs were deleted and pass a '_destroy' => 1 parameter. This is messy logic that I'd rather avoid; I just want objects deleted unless they are explicitly included in the parameters. allows_nested_attributes_for doesn't support this behavior as far as I can tell, so I'm looking to implement my own solution.
What's the most efficient (in terms of database access) way to do this kind of update? Do I delete everything and rebuild the list from scratch? Do I load the association and pick out objects that aren't explicitly included? Perhaps there's some clever ActiveRecord magic I can use?
My personal feeling is that doing this using the :destroy => 1 flag set a lot less messy than the alternative. The alternative would be loading the association on the server, comparing the incoming parameters, figuring out which records are missing, then deleting the missing ones and updating the remaining ones. That's a lot of extra logic, DB operations, and worst of all, you'll have to hand-rework the accepts_nested_attributes_for which is a non-trivial feat.
HTML give you a little trick/hack to accomplish this without JS. Add a checkbox to each record with name :destroy. Use the high-level form helpers, e.g. check_box, not check_box_tag (which requires a lot of things to get right manually), or a higher level form helper such as the simple_form gem.
If the flag is not checked, then HTML won't submit anything, and the record stays. If the flag is checked, HTML will submit the :destroy flag, and it will be deleted with the built-in server-side mechanisms out of the box.
You didn't say much about your front-end code; it sounds like you have a bunch of JS on there. You probably hide the record when the user "removes" it, you can simply add the destroy flag programmatically in that case, if you don't want to use the check box method above. This will be a lot simpler and less error prone than trying to second-guess the backend behavior.
An example problem:
On Stack Overflow, a question page shows a number of different answers. In displaying these answers, the site also gives information about the author of the answer. This means that although the number of badges a given user has has nothing to do with an answer in and of itself, that data still needs to be retrieved in order to display the page.
From what I can see, there are three different ways to go about pulling this view data in a model:
A Post object could include a full User object as a member. The view would then access the user like this: $post->user->getReputation(). This seems cleaner, since a Controller could just request the posts and be done with it, but yet inefficient since a Post probably doesn't always need a full-blown User. I suppose it works well enough if the User object is relatively light, which it probably would be. The problem would then be that you would need to duplicate User retrieval code as part of the Post retrieval query.
The Post object could hold just an ID for a User. When the Post, or Posts, are returned to the Controller, the Controller could then extract the unique User IDs from the returned set and pass them to a User factory. The returned User objects would then be passed along with the original Posts set to the View as a separate collection. The view could then grab user info using something like $users[$post->getUserId()]->getReputation().
A hybrid approach: Include the User object inside the Post object, but have the unique id extraction and User retrieval as part of the Post retrieval method. i.e. Post::getPosts() would grab all relevant posts and convert them to objects with null User members, then it'd extract all user ids and pass them to User::getUsers(), then assign the Users to the relevant Posts before returning the set of Posts to the caller.
I guess what I'm getting at is, how do I know when an object needs to contain another object fundamentally? Is it unclean/a code smell to instead have such related objects returned separately, with neither object knowing the other has been retrieved. I'm leaning towards the separate retrieval concept - it seems the most efficient - but it really does feel like they're too related for that to make sense.
There is also a solution in between 1 and 2. You can have a lazy loading proxy for the user class. With this solution you can have best of both worlds because the proxy is interchangeable with the real thing so depending on the situation you can have the object itself or the proxy.
Edit:
I'll try to explain this with an example.
Say that you have a view where you don't need user info, then you can instruct/configure your post factory to use the lazy proxy (see wikipedia)for the user which will only contain an ID. So no access to users is needed.
In another view you occasionally need to access user info but only for some posts, here again you instruct/configure your factory to include the lazy proxy for the user.
But when you actually need access to the user info, you can access the proxy object that will then load the actual user object and redirect messages to it.
In yet another view you need both post and user info, so here you instruct your post factory to use actual user objects.
It seems to me that this is another case of dependency injection. A general enough idea that could help you.
DEPENDENCY INJECTION WIKI
Read something about the Inversion Of Control also.
why not add optional member to model to know informations?? you can ignore when you don't need and can use when you do need.