Hi,

I just started using Tracks and I think I might have found a bug.

Last semester I had database class and I was playing with postgresql. That’s why I used this DBMS for Tracks, too. In class I had to implement something and stumbled upon a problem, that seems to be the same that I found in Tracks. When selecting something while at the same time using an aggregate function (e.g. count), one has to put all the fields one wants to select into a GROUP BY clause.

The error message I get is: “PGError: ERROR: column ‘todos.due’ must appear in the GROUP BY clause..”. So I tried to fix the two controllers where this is the case, but there are so many more fields selected, that I can’t put all of them into the GROUP BY clause. I don’t know how to fix this and still be dynamic (not put all the fields into the GROUP BY).
How I noticed the error in the beginning is, that when I add an action it shows a “server error” (whatever that means) and I have to reload “Home” to see the new action.

Also, I cannot delete projects. Another “PGError: ERROR: null value in column ‘position’ violates not-null constraint”. Okay, so there is a not null constraint on position which probably does make sense. Now I wonder, why Tracks/Rails wants to UPDATE the project instead of DELETEing it. In the projects controller I only found a destroy method and in the Rails API there is a DELETE, so I don’t understand where the UPDATE comes from, but there it has to be fixed.

Regards,
Frank

These are known problems. We have fixed them both. The fixes will be in the next release.

The fixes are also available in trunk which you can checkout using svn.

Did you run {{{rake db:migrate}}} when you upgraded to 1.5? the second error should be fixed by running migration 38 which removed the not-null constraint from the db.

Oh. I didn’t find them in the forums. Where are the known problems listed?

Actually I didn’t upgrade but made a fresh install of 1.5. That’s what it said on the package. So I will try to remove the not null constraint manually. You’re right, there is such a migration, which should fix that. I don’t know why it still has that constraint. Anyway, fixed.

ok, your first error is indeed a bug in 1.5 final. The fix is in trunk.

It is strange though that the migration did not work for you. How did you create the database? A fresh CREATE DATABASE followed my rake db:migrate ?

btw, you can view all tickets on http://dev.rousette.org.uk

Yeah, a CREATE DATABASE and then db:migrate as in the INSTALL/HOWTO or whatever. I will try the exact same steps again and then let you know if it still didn’t work or if I mixed something up in the first installation procedure.

Hm, I didn’t find the fix in the trunk.

Btw, I don’t know if it’s me, but the Trac site is quite slow.

the fix is here: http://dev.rousette.org.uk/changeset/806

uhm.. maybe I am doing something wrong here, but this fix cannot fix my problem. I tried it anyway, and it didn’t. A GROUP BY by id doesn’t GROUP BY todos.due. I assume that is necessary because of the ORDER BY?

hmm, maybe I was to quick then :-( could you post a stack trace from your log? So I can see where exactly the error occures?

Sure thing. I will try to focus on the important things though, because I’ve got the stack trace on another computer.

The ‘..’ means that there are some lines inbetween. I hope this information is enough to localize the bug. As I was writing in a previous post, I think a GROUP BY is necessary, because there is a count() in there. Anyway.. if you need any other information, just tell me. I suppose putting all the fields into the :group would also help?

ok, looking at your stack trace, it is the same error that was fixed in trunk.

I forgot to mention that http://dev.rousette.org.uk/changeset/804 is also part of the fix. So first this patch 804 and then the fix in 806.

Ah, okay, that did it. Thanks.

What happens now, though is, that when I add an action, a row of numbers appear on the top left, where usually there is the numbers of items (actions). Also when deleting this row of numbers (51161171211231) appears. Is this the way it’s supposed to be?

hmm, I guess it would be better to update to latest trunk. you get all the patches to 1.5 including a fix for the row of numbers. What you are doing now anyway is patching 1.5 with patches from trunk, so why not running trunk Currently there are only bigfixes in trunk and no other changes, so you’ll be safe.