What I’m trying to do is to group by a field that I have to join in (in two steps). In this case it’s a tag name. (An account belongs to a user and has many transactions. A transaction has, and belongs to, many tags.) The full SQL of the (hand-written) query is:
SELECT sum(ABS(amount)), tags.name
FROM transactions
INNER JOIN accounts ON transactions.account_id = accounts.id
INNER JOIN tags_transactions tt ON transactions.id = tt.transaction_id
INNER JOIN tags ON tt.tag_id = tags.id
WHERE ((accounts.user_id = 1))
GROUP BY tags.name;


Update 2009-10-09: The answer was simple. You can write it like this
group = user.transactions.sum('ABS(amount)', :joins => :tags, :group => 'tags.name')and Rails will figure out how to join in ‘tags’ (which is specified in the models). Should have tried that first…

Most posts that I have read about combining users and tagging was about adding the user scope to the tagging, which means that you still have a global set of tags (for example like del.icio.us). I wanted each user to have his, or her, own set of tags – a tag belongs to a user – like Gmail.

This is how I did it:

I used the tagging generator that comes with HMP and generate the Tag and Tagging models. From before, I had the User and Transfer (my taggable) models. Each Transfer belongs to a User.

To the Tag model, add “belongs_to :user” and “validates_uniqueness_of :name, :scope => [:user_id, :name]“.

Add “belongs_to :user” to the Tagging model. The taggings will belong to a user through the tag (and also through the taggable in my case, but that shouldn’t be a requirement).

You also need to modify the “_add_tags” function in the generated file “lib/tagging_extensions.rb”. When the Tag is found or created, you need to do “tag = Tag.find_or_create_by_name_and_user_id(tag_name, user.id)”, instead of “tag = Tag.find_or_create_by_name(tag_name)”, which I believe it was originally. Otherwise it doesn’t set the user_id in the tag.

Of course you have to update your migrations for the Tag model. You need to add a user_id column to it.

That should be it, but I might have forgotten something.

(Thanks to Alexander Hoth for the idea to this post.)

if (value != null && (element.type != 'submit' || (!submitted &&
    submit !== false && (!submit || key == submit) && (submitted = true)))) {

It’s from a changeset in Prototype’s Trac page and is supposed to fix this bug.

The reason I started reading the code was that I’m using multiple submit tags with different names. Instead of just varying the value, I set the type tag to “submit”. Example:

<input name="create" value="Create New..." type="submit" />

and in Rails I check if params[:create] is set to see if that button was pressed or not. Perhaps this is really bad for some reason that I have missed, I don’t know (it does work in my version of IE6 aswell), but the fix doesn’t solve my problem. It just solves when using multiple input tags with the name submit and vary the name. The reason I don’t like looking what the value attribute is set to, is that it’s part of the design and should be free to change, without having to modify the controller. Of course, hidden values are always an alternative, but requiring Javascript to use a simple form seems wrong.

Anyway, I opened up my prototype.js and started reading the code and found the above piece of code. Note the assignment in the end of the second row. I think it’s intentional.

Oh the title, I’m so funny! I have to be the first one to ever think of that. Right…

This became another text in English, mainly because the follow up (if I write it) could possibly be useful to more people. We’ll see what happens.

Anyway, about a month ago, I decided to learn a bit of Ruby on Rails. I hadn’t tried Ruby before either, so learning Ruby was/is part of the process, but you can come a long way without having to study the language very deep. Most stuff works as you think they would, after learning the basics. In general I think it’s a nice language, but my knowledge isn’t very good yet.

Rails is wonderful to work with in general. I haven’t really done any web development in many years now (except for some minor WordPress hacking to modify it for my needs, but even that was more than a year ago, and a simple summer course two years ago). Back then I knew a lot less (doh!) and most stuff I wrote was quite poorly written, I realize now, in terms of flexibility and security (Hello SQL injection!). I sure as hell wrote all my SQL statements by hand, though they were quite simple, and in general it usually became quite a mess quickly. I’m sure there existed some projects that the same idea as Rails, but I didn’t know about them then.

Something that is a bit annoying now, is that for my project I wanted two things; tags and pagination (split up something over several pages, to give the user a better overview. Nothing fancy really). As it turns out, the built-in paginate module is deprecated and will be removed in the next version (it’s already gone from Edge Rails) and both the gem and plugin named acts_as_taggable are old and bad, in different ways (they aren’t the same).

The pagination wasn’t hard to solve. I found the plugin will_paginate, which works great. All good. For now…

The tagging wasn’t quite as easy. There are quite a few plugins that tries to (and does) fix what acts_as_taggable did, but better. One is has_many_polymorphs, which is a fair bit more complex and flexible, but I didn’t really need that. The guide he has, on his blog, to use the plugin for tagging is about converting from acts_as_taggable to has_many_polymorphs, which includes a bit more work than it felt worth it for me. I ended up using acts_as_taggable_on_steroids (puh, long name) which is quite simple. It has (or had, I haven’t checked the last version yet) a bug with migrations, but in general it was easy to work with and to work around the bug.

I also wanted to tie my tags to users, because the project isn’t about a community and all user data is private to each user. There’s also a third plugin for tagging, acts_as_taggable_redux, and it has user support already, but it turns out that he ties the tagging (the connection between the tag and the item) to the user instead of the tag. That’s great for community like sites, like last.fm, where all tags are global, but that wasn’t what I wanted. I also found a post about adding user support to acts_as_taggable, but it had the same user connections. Instead I decided that it was easy enough to do myself. I’m not saying that it’s hard, it’s not, but if someone else had done it already and had working plugin, I would rather use that).

It turned out to be even easier than I imagined at first. Rails has some really great tools. After adding a simple user_id column to the tag model, I could do things like

user.tags.find_by_name(tag_name)

which looks great in terms of readability. I might post a summary later on what I changed to get this working.

Now to the real problem: get them to work together. It wasn’t quite as easy to get will_paginate to work with acts_as_taggable_on_steroids. Find_tagged_with works directly on the type you want to tag, but will_paginate does that too. There might be easier ways than how I solved it, I don’t claim to be an expert after just a week (when I did this) with RoR. My solution wasn’t very nice either. I basically runs find_tagged_with, but returns the database request, instead of executing it and returning the result, modify the SQL statement a bit and then use paginate_by_sql to turn it into a paginatable (cute word) object. The correct solution is probably to modify how acts_as_taggable_on… works and extend it with the things needed to paginate the results. If I understand the comments on the acts_as_taggable_on_steroid page, someone might have done that now. I have to read up on that.

MTV visar just nu videon till Kanye Wests låt Stronger. Jag misstänker att jag kommer att få se den många gånger från till, men det gör inget för det är en mycket bra låt.