What do you mean by 'delete a context'? You mean something like this - you have an item with say home associated with it and now you edit the item to remove the context completely (blank) and try to save the change?

In my synced-to-head-long-ago version, the save action produces no change since an item cannot have a blank context. Try creating a new item with a blank context. You should get the error "Context can't be blank". I use MySQL on my backend.

No, I don't mean editing an action. I mean go to 'Contexts' at the top menu, then click the red (on mouseover) 'x' on the right for one of the contexts listed. This winds up in app/controllers/contexts_controller.rb line 99:

    @context.destroy
}}}

That line causes several SQL calls to be executed.  Here is a full log (minus the backtrace):

{{{
Processing ContextsController#destroy (for 63.245.220.241 at 2008-02-07 23:51:13) [DELETE]
  Session ID: 3e63757af959aab14744d8165e8c1cf4
  Parameters: {"format"=>"js", "_method"=>"delete", "action"=>"destroy", "id"=>"13", "controller"=>"contexts"}
  User Load Including Associations (0.004748)   SELECT users."id" AS t0_r0, users."login" AS t0_r1
, users."crypted_password" AS t0_r2, users."token" AS t0_r3, users."is_admin" AS t0_r4, users."first_name" AS t0
_r5, users."last_name" AS t0_r6, users."auth_type" AS t0_r7, users."open_id_url" AS t0_r8, users."remember_token
" AS t0_r9, users."remember_token_expires_at" AS t0_r10, preferences."id" AS t1_r0, preferences."user_id" AS t1_
r1, preferences."date_format" AS t1_r2, preferences."week_starts" AS t1_r3, preferences."show_number_completed" 
AS t1_r4, preferences."staleness_starts" AS t1_r5, preferences."show_completed_projects_in_sidebar" AS t1_r6, pr
eferences."show_hidden_contexts_in_sidebar" AS t1_r7, preferences."due_style" AS t1_r8, preferences."admin_email
" AS t1_r9, preferences."refresh" AS t1_r10, preferences."verbose_action_descriptors" AS t1_r11, preferences."sh
ow_hidden_projects_in_sidebar" AS t1_r12, preferences."time_zone" AS t1_r13, preferences."show_project_on_todo_d
one" AS t1_r14, preferences."title_date_format" AS t1_r15, preferences."mobile_todos_per_page" AS t1_r16 FROM us
ers LEFT OUTER JOIN preferences ON preferences.user_id h1.  1) 
  Context Load (0.001693)   SELECT * FROM contexts WHERE (contexts."id" = 13 AND (contexts.user_
id = 1)) ORDER BY position ASC
** has_many_polymorphs: associating Tag.taggables
** has_many_polymorphs: injecting dependencies
  Todo Delete all (0.001400)   DELETE FROM todos WHERE (context_id = 13) 
  Context Update (0.000666)   UPDATE contexts SET position h1.  1 A
ND position > 8) 
  Context Update (0.000000)   SQLite3::SQLException: contexts.position may not be NULL: UPDATE con
texts SET "created_at" h1.  
'2008-02-08 04:51:13', "user_id" h1.  13


ActiveRecord::StatementInvalid (SQLite3::SQLException: contexts.position may not be NULL: UPDATE contexts SET "c
reated_at" h1.  '2008-02-08 
04:51:13', "user_id" h1.  13):

Is there an irc channel that I can hang out on? I could revert my workaround to help test this problem with someone who knows the code/rails a little more than I.

I guess an alternate workaround to mine (removing the NOT NULL constraint from the position column) could be to create a destroy method in the context model which just executes a DELETE instead of all that junk. But it would be better for it to be fixed deeper down by someone who understands why AR is executing all of those queries.

I can confirm that tests fail using sqlite; MySQL works like a charm. I had to change schema.rb (:null => true for all position fields).

Maybe it's a sqlite driver problem?

1.043 does not show this problem. trunk does. The NOT NULL is there in both versions.

"Line 126 of the acts as list code":http://dev.rousette.org.uk/browser/trunk/tracks/vendor/rails/activerecord/lib/active_record/acts/list.rb#L126 shows where rails attempts to set the position to null. I think the "workaround" of removing the not null constraint is actually more in keeping with the code base than having it there.

I've tried he following migration to remove the NOT NULL constraint. It works for mysql, but not for sqlite. Any comments? ideas??

class ProjectsRemoveNotNullFromPosition < ActiveRecord::Migration
  def self.up
    change_column :projects, :position, :string, :null => true
  end

  def self.down
    @projects = Project.find(:all)
    @projects.each do |project|
      project.position = 0 if !project.position?
      project.save
    end
    change_column :projects, :position, :string, :null => false
  end
end

found out why the migration does not work. It's in rails 1.2.5. When you look at http://dev.rousette.org.uk/browser/trunk/tracks/vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb#L255 it does nothing with the option :null

looking at rails 2.0, this bug is fixed, see http://dev.rubyonrails.org/browser/branches/2-0-stable/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb#L234

if you thus add

 self.null    = options[:null] if options.include?(:null)

the migration works

So I guess its ok to patch our copy of rails in Tracks in order to get the migration working. When we upgrade rails after 1.5, the change is not lost. I'll try this tonight

In [722] I've added a migration for position in both projects and contexts. Also I've patched rails included in tracks as mentioned in my previous comment.

After the migration, I can remove contexts and projects that contain actions without error.

Please reopen if this does not work for you.