I’m curious about the new version and I’d like to check out all the new features

So I checked out the trunk version of tracks, but I’m having a bit of trouble getting my sqlite3 database to work properly. Here’s what I did:

I then set all the necessary Tracks knobs and dials to the right setting (db type and path in database.yml and salt in environment.rb)
According to the documentation, I then have to run “rake migrate”, however, that fails:

If that means it is trying to remove a column from the table, then I know what’s wrong: SQLite3 does not support dropping of columns…
Is there another way of getting this to setup properly?

In db/schema.rb is a file that represents the current database schema in ruby. You should be able to create a sql-lite-3 database with that somehow. We’ll get a smooth path in place for the next release, but as of now, I think bsag and I are mostly doing day-to-day development against mysql.

I’ve switched to MySQL and have had a little more luck.

However, the rake migrate task still has problems.
This time it seems to hiccup on adding the indexes to the tables. It seems to fail because the todos table does not have a state column.
I added that manually, but it still seemed to have problems, so in the end I just added the state column by myself.

Also the state column in the projects table was not added and the completed in todos was not renamed to completed_at.

I’m not very familiar with the rake migrate task, I guessed it would run all the scripts in db/migrate/. If that is the case, then there seems to be a mismatch with what is happening there and the schema in db/schema.rb

Basically, what rake migrate does is check the current version of the database by looking for a table called (I think) schema_version. It then runs all migrations greater than that number in order. The state column should have been added to the projects table in 014 and to the todo table in 019.

Anyway, I’m glad you were able to muddle through and look forward to your feedback!

Hmm, this whole procedure may need to have some more looking into.

IMHO it might make more sense to try the proper SQL to update to the present schema, and then look at what kind of errors you get back. That, or be a little bit more conservative with updating the version number…

Where is the code that handles the “rake migrate” task by the way?

Gobo - 17 January 2007 07:37 PM

Hmm, this whole procedure may need to have some more looking into.

Feel free. It’s important to get a good upgrade process in place before the next release.

Gobo - 17 January 2007 07:37 PM

IMHO it might make more sense to try the proper SQL to update to the present schema, and then look at what kind of errors you get back. That, or be a little bit more conservative with updating the version number…

Where is the code that handles the “rake migrate” task by the way?

ActiveRecord migrations are a feature of Ruby on Rails and are within the codebase in vendor/rails. You should read up on them to get an understanding of how they work and how they’re designed to be used in the development of Rails apps.

Cheers,
Luke

I just tried using the trunk (revision 410) with a fresh start.  The migration from an empty database worked nicely.  However, I couldn’t use the software.  The login controller, recognizing that this is a fresh install, redirects to the signup action.  But there is no signup action in the login controller, and ultimately an error is generated/logged about not finding a view login/index.rhtml.

Hi Eric,

I changed a lot of code in there recently. What you describe is likely a bug introduced there. Please open a ticket or submit a patch on the Trac and hopefully I can fix this in the next couple of days.

Cheers,
Luke

FYI. The problem is fixed in revision 411.