JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-1905

ALTER TABLE failure using jdbcderby during rails migration adding a column with 'not null' constraint

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      MacOS X 10.4.11, Java 1.5.0_13, JRuby trunk r5512, rails 2.0.2, activerecord-jdbc-adapter 0.7.1, activerecord-jdbcderby-adapter 0.7.1
    • Number of attachments :
      4

      Description

      Migrating a set of migrations from mysql to derby I found that I couldn't create columns in a derby database with a 'NOT NULL' constraint unless I also set a default value.

      It is common in rails apps to set ":null => false" as a column constraint without specifying a default value.

      Perhaps this is not an error in the jdbcderby adaptor but instead a function of how Derby itself operates.

      Here's a simple test case.

      Create a simple rails testapp:

      $ rails testapp --database mysql
      

      Edit config/database.yml to use derby instead of mysql:

      $ cat config/database.yml 
      development:
        adapter: jdbcderby
        database: db/development.derby
        timeout: 5000
      
      test:
        adapter: jdbcderby
        database: db/test.derby
        timeout: 5000
      
      production:
        adapter: jdbcderby
        database: db/production.derby
        timeout: 5000
      

      Create a scaffold with a migration:

      $ jruby script/generate scaffold widget name:string description:text
      

      Here's what the schem looks like now:

      $ cat db/schema.rb                
      ActiveRecord::Schema.define(:version => 1) do
      
        create_table "widgets", :force => true do |t|
          t.string    "name"
          t.text      "description"
          t.timestamp "created_at"
          t.timestamp "updated_at"
        end
      
      end
      

      Create a new migration adding a column:

      $ cat db/migrate/002_add_field.rb 
      class AddField < ActiveRecord::Migration
        def self.up
          add_column :widgets, :color, :string, :null => false
        end
      
        def self.down
          remove_column :widgets, :function
        end
      end
      

      The migration fails:

      $ rake db:migrate
      (in /Users/stephen/dev/jruby/rails/testapp)
      == 2 AddField: migrating ======================================================
      -- add_column(:widgets, :color, :string, {:null=>false})
      rake aborted!
      ActiveRecord::ActiveRecordError: In an ALTER TABLE statement, the column 'COLOR' has been specified as NOT NULL and either the DEFAULT clause was not specified or was specified as DEFAULT NULL.: ALTER TABLE widgets ADD color varchar(256) NOT NULL
      

      If instead a default value is added to the new column definition:

      add_column :widgets, :color, :string, :null => false, :default => 'red'
      

      The migration succeeds.

        Activity

        Hide
        Stephen Bannasch added a comment -

        However initially creating a table with a column with a 'NOT NULL' constraint and with no default value does work.

        Here's the sole migration on the new test now:

        [~/dev/jruby_trunk/jruby/rails/testapp]$ cat db/migrate/001_create_widgets.rb 
        class CreateWidgets < ActiveRecord::Migration
          def self.up
            create_table :widgets do |t|
              t.string :name
              t.text :description
              t.string :color, :null => false
        
              t.timestamps
            end
          end
        
          def self.down
            drop_table :widgets
          end
        end
        

        The migration now runs successfully:

        [~/dev/jruby_trunk/jruby/rails/testapp]$ rake db:migrate
        (in /Users/stephen/dev/jruby/rails/testapp)
        == 1 CreateWidgets: migrating =================================================
        -- create_table(:widgets)
           -> 0.0550s
           -> 0 rows
        == 1 CreateWidgets: migrated (0.0570s) ========================================
        

        Here's the complete schema:

        [~/dev/jruby_trunk/jruby/rails/testapp]$ cat db/schema.rb                     
        
        ActiveRecord::Schema.define(:version => 1) do
        
          create_table "widgets", :force => true do |t|
            t.string    "name"
            t.text      "description"
            t.string    "color",       :null => false
            t.timestamp "created_at"
            t.timestamp "updated_at"
          end
        
        end
        
        Show
        Stephen Bannasch added a comment - However initially creating a table with a column with a 'NOT NULL' constraint and with no default value does work. Here's the sole migration on the new test now: [~/dev/jruby_trunk/jruby/rails/testapp]$ cat db/migrate/001_create_widgets.rb class CreateWidgets < ActiveRecord::Migration def self.up create_table :widgets do |t| t.string :name t.text :description t.string :color, : null => false t.timestamps end end def self.down drop_table :widgets end end The migration now runs successfully: [~/dev/jruby_trunk/jruby/rails/testapp]$ rake db:migrate (in /Users/stephen/dev/jruby/rails/testapp) == 1 CreateWidgets: migrating ================================================= -- create_table(:widgets) -> 0.0550s -> 0 rows == 1 CreateWidgets: migrated (0.0570s) ======================================== Here's the complete schema: [~/dev/jruby_trunk/jruby/rails/testapp]$ cat db/schema.rb ActiveRecord::Schema.define(:version => 1) do create_table "widgets" , :force => true do |t| t.string "name" t.text "description" t.string "color" , : null => false t.timestamp "created_at" t.timestamp "updated_at" end end
        Hide
        Stephen Bannasch added a comment -

        There is no error running the original set of two migrations with v0.7.1 of activerecord-jdbcmysql-adapter

        Show
        Stephen Bannasch added a comment - There is no error running the original set of two migrations with v0.7.1 of activerecord-jdbcmysql-adapter
        Hide
        Stephen Bannasch added a comment -

        I created a newer jdbc-derby gem with v10.3.2.1 of Derby and tried using that:

        $ gem install jdbc-derby-10.3.2.1.gem                         
        Successfully installed jdbc-derby-10.3.2.1
        1 gem installed
        Installing ri documentation for jdbc-derby-10.3.2.1...
        Installing RDoc documentation for jdbc-derby-10.3.2.1...
        

        But the same ALTER TABLE error still occurs

        Show
        Stephen Bannasch added a comment - I created a newer jdbc-derby gem with v10.3.2.1 of Derby and tried using that: $ gem install jdbc-derby-10.3.2.1.gem Successfully installed jdbc-derby-10.3.2.1 1 gem installed Installing ri documentation for jdbc-derby-10.3.2.1... Installing RDoc documentation for jdbc-derby-10.3.2.1... But the same ALTER TABLE error still occurs
        Hide
        Stephen Bannasch added a comment -

        Derby itself does not appear to allow the addition of a table column with a constraint of NOT NULL without also specifying a default value in a single SQL statement. Splitting this request into two sequential SQL statements (ADD COLUMN followed by ALTER COLUMN) does work.

        see: http://db.apache.org/derby/docs/10.3/ref/rrefsqlj81859.html#rrefsqlj81859__rrefsqlj37860

        However, a column with a NOT NULL constraint can be added to an existing table if you give a default value; otherwise, an exception is thrown when the ALTER TABLE statement is executed.

        I'm going to see if I this can be fixed in the activerecord-jdbcderby-adapter.

        Here's some tests on derby using the Deby command line tools ij. The test results are the same on Derby 10.2.2.0 and 10.3.2.1,

        Creating a table with a column with a NOT NULL constraint AND no default value works:

        ij> CONNECT 'jdbc:derby:testdb;create=true';
        ij> CREATE TABLE FIRSTTABLE 
            (ID INT PRIMARY KEY, 
            NAME VARCHAR(12),
            COLOR VARCHAR(12) NOT NULL);
        0 rows inserted/updated/deleted
        
        ij> describe FIRSTTABLE;
        COLUMN_NAME         |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        ID                  |INTEGER  |0   |10  |10    |NULL      |NULL      |NO      
        NAME                |VARCHAR  |NULL|NULL|12    |NULL      |24        |YES     
        COLOR               |VARCHAR  |NULL|NULL|12    |NULL      |24        |NO      
        

        Creating a table first and then adding a column with a NOT NULL constraint AND no default value fails:

        ij> CREATE TABLE SECONDTABLE 
            (ID INT PRIMARY KEY, 
            NAME VARCHAR(12));
        0 rows inserted/updated/deleted
        
        ij> ALTER TABLE SECONDTABLE ADD COLUMN COLOR VARCHAR(12) NOT NULL; 
        ERROR 42601: In an ALTER TABLE statement, the column 'COLOR' has been specified as NOT NULL and either the DEFAULT clause was not specified or was specified as DEFAULT NULL.
        
        ij> describe SECONDTABLE;
        COLUMN_NAME         |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        ID                  |INTEGER  |0   |10  |10    |NULL      |NULL      |NO      
        NAME                |VARCHAR  |NULL|NULL|12    |NULL      |24        |YES     
        

        Creating a table and adding a column with with no constraints and then adding a NOT NULL constraint to that column in a subsequent SQL statement *does works:

        ij> CREATE TABLE THIRDTABLE 
            (ID INT PRIMARY KEY, 
            NAME VARCHAR(12));
        0 rows inserted/updated/deleted
        
        ij> ALTER TABLE THIRDTABLE ADD COLUMN COLOR VARCHAR(12);
        0 rows inserted/updated/deleted
        
        ij> ALTER TABLE THIRDTABLE ALTER COLUMN COLOR NOT NULL;
        0 rows inserted/updated/deleted
        
        ij> describe FIRSTTABLE;
        COLUMN_NAME         |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        ID                  |INTEGER  |0   |10  |10    |NULL      |NULL      |NO      
        NAME                |VARCHAR  |NULL|NULL|12    |NULL      |24        |YES     
        COLOR               |VARCHAR  |NULL|NULL|12    |NULL      |24        |NO      
        
        Show
        Stephen Bannasch added a comment - Derby itself does not appear to allow the addition of a table column with a constraint of NOT NULL without also specifying a default value in a single SQL statement. Splitting this request into two sequential SQL statements ( ADD COLUMN followed by ALTER COLUMN ) does work. see: http://db.apache.org/derby/docs/10.3/ref/rrefsqlj81859.html#rrefsqlj81859__rrefsqlj37860 However, a column with a NOT NULL constraint can be added to an existing table if you give a default value; otherwise, an exception is thrown when the ALTER TABLE statement is executed. I'm going to see if I this can be fixed in the activerecord-jdbcderby-adapter . Here's some tests on derby using the Deby command line tools ij. The test results are the same on Derby 10.2.2.0 and 10.3.2.1, Creating a table with a column with a NOT NULL constraint AND no default value works : ij> CONNECT 'jdbc:derby:testdb;create= true '; ij> CREATE TABLE FIRSTTABLE (ID INT PRIMARY KEY, NAME VARCHAR(12), COLOR VARCHAR(12) NOT NULL); 0 rows inserted/updated/deleted ij> describe FIRSTTABLE; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ ID |INTEGER |0 |10 |10 |NULL |NULL |NO NAME |VARCHAR |NULL|NULL|12 |NULL |24 |YES COLOR |VARCHAR |NULL|NULL|12 |NULL |24 |NO Creating a table first and then adding a column with a NOT NULL constraint AND no default value fails : ij> CREATE TABLE SECONDTABLE (ID INT PRIMARY KEY, NAME VARCHAR(12)); 0 rows inserted/updated/deleted ij> ALTER TABLE SECONDTABLE ADD COLUMN COLOR VARCHAR(12) NOT NULL; ERROR 42601: In an ALTER TABLE statement, the column 'COLOR' has been specified as NOT NULL and either the DEFAULT clause was not specified or was specified as DEFAULT NULL. ij> describe SECONDTABLE; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ ID |INTEGER |0 |10 |10 |NULL |NULL |NO NAME |VARCHAR |NULL|NULL|12 |NULL |24 |YES Creating a table and adding a column with with no constraints and then adding a NOT NULL constraint to that column in a subsequent SQL statement *does works: ij> CREATE TABLE THIRDTABLE (ID INT PRIMARY KEY, NAME VARCHAR(12)); 0 rows inserted/updated/deleted ij> ALTER TABLE THIRDTABLE ADD COLUMN COLOR VARCHAR(12); 0 rows inserted/updated/deleted ij> ALTER TABLE THIRDTABLE ALTER COLUMN COLOR NOT NULL; 0 rows inserted/updated/deleted ij> describe FIRSTTABLE; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ ID |INTEGER |0 |10 |10 |NULL |NULL |NO NAME |VARCHAR |NULL|NULL|12 |NULL |24 |YES COLOR |VARCHAR |NULL|NULL|12 |NULL |24 |NO
        Hide
        Stephen Bannasch added a comment -

        The attached patch for activerecord-jdbc-adapter and activerecord-jdbcderby-adapter:

        1. Adds a test for creating a new column with a NOT NULL constraint, with no default value
        2. Fixes the activerecord-jdbcderby-adapter to pass this test.

        I also ran the test for mysql and they still all pass also.

        There are changes to these files:

        • M test/simple.rb
        • M test/jdbc_common.rb
        • M lib/jdbc_adapter/jdbc_derby.rb

        This is a new file:

        • A test/models/add_not_null_column_to_table.rb
        Show
        Stephen Bannasch added a comment - The attached patch for activerecord-jdbc-adapter and activerecord-jdbcderby-adapter: Adds a test for creating a new column with a NOT NULL constraint, with no default value Fixes the activerecord-jdbcderby-adapter to pass this test. I also ran the test for mysql and they still all pass also. There are changes to these files: M test/simple.rb M test/jdbc_common.rb M lib/jdbc_adapter/jdbc_derby.rb This is a new file: A test/models/add_not_null_column_to_table.rb
        Hide
        Stephen Bannasch added a comment -

        Tests failed for hsqldb. Copying my new add_column to jdbc_hsqldb.rb fixes that failure.

        Updated patch includes that change.

        Show
        Stephen Bannasch added a comment - Tests failed for hsqldb. Copying my new add_column to jdbc_hsqldb.rb fixes that failure. Updated patch includes that change.
        Hide
        Nick Sieger added a comment -

        Had to make a small fix to the test for postgres, and include a default value for the column, since pgsql won't let you do that all in one go.

        Will be fixed in 0.7.2.

        Show
        Nick Sieger added a comment - Had to make a small fix to the test for postgres, and include a default value for the column, since pgsql won't let you do that all in one go. Will be fixed in 0.7.2.
        Hide
        Stephen Bannasch added a comment -

        The test in the earlier patches wasn't quite right. I was adding a column which had a constraint of NOT NULL to a table already setup by another test with records inserted. The only reason the test passed is because the fix to make this work was only partially implemented and it never actually applied the NOT NULL constraint.

        I realized the fix was incomplete and finished it – then the test failed because it didn't actually make any sense to add a NOT NULL column to a table with existing values (without specifying the default). I updated the tests so that this test is run on it's own table with no existing records.

        This fix did not cleanly apply to hsqldb so I removed that addition from this patch. Right now the new test fails in hsqldb. The mysql tests still pass. I'll bet it's a simple fix for hsqldb also – but it's late ...

        Here is the list of changed and added files now.

        • A test/models/widgets.rb
        • A test/models/add_not_null_column_to_widgets.rb
        • M test/simple.rb
        • M test/jdbc_common.rb
        • M lib/jdbc_adapter/jdbc_derby.rb

        This is in effect what the incorrect test was trying to do:

        CREATE TABLE FOURTHTABLE 
            (ID INT PRIMARY KEY, 
            NAME VARCHAR(12));
        
        INSERT INTO FOURTHTABLE VALUES (1, 'Vermont');
        
        ALTER TABLE FOURTHTABLE ADD COLUMN COLOR VARCHAR(12);
        
        ALTER TABLE FOURTHTABLE ALTER COLUMN COLOR NOT NULL;
        
        Show
        Stephen Bannasch added a comment - The test in the earlier patches wasn't quite right. I was adding a column which had a constraint of NOT NULL to a table already setup by another test with records inserted. The only reason the test passed is because the fix to make this work was only partially implemented and it never actually applied the NOT NULL constraint. I realized the fix was incomplete and finished it – then the test failed because it didn't actually make any sense to add a NOT NULL column to a table with existing values (without specifying the default). I updated the tests so that this test is run on it's own table with no existing records. This fix did not cleanly apply to hsqldb so I removed that addition from this patch. Right now the new test fails in hsqldb. The mysql tests still pass. I'll bet it's a simple fix for hsqldb also – but it's late ... Here is the list of changed and added files now. A test/models/widgets.rb A test/models/add_not_null_column_to_widgets.rb M test/simple.rb M test/jdbc_common.rb M lib/jdbc_adapter/jdbc_derby.rb This is in effect what the incorrect test was trying to do: CREATE TABLE FOURTHTABLE (ID INT PRIMARY KEY, NAME VARCHAR(12)); INSERT INTO FOURTHTABLE VALUES (1, 'Vermont'); ALTER TABLE FOURTHTABLE ADD COLUMN COLOR VARCHAR(12); ALTER TABLE FOURTHTABLE ALTER COLUMN COLOR NOT NULL;
        Hide
        Stephen Bannasch added a comment -

        I'm re-opening this issue because I found a bug in my first two patches. Nick applied my second patch.

        I added a third patch but this was against the original svn checkout.

        I'll add a fourth patch against head after this change in ticket status.

        Unfortunately I've found another bug in the Derby adaptor relating to text fields and limits larger than 16k (actually somewhere between 16 and 32 k).

        I've added tests for this which pass in mysql but not in derby.

        Don't have a fix yet but the test are intermixed with the tests for the NOT NULL issue.

        Show
        Stephen Bannasch added a comment - I'm re-opening this issue because I found a bug in my first two patches. Nick applied my second patch. I added a third patch but this was against the original svn checkout. I'll add a fourth patch against head after this change in ticket status. Unfortunately I've found another bug in the Derby adaptor relating to text fields and limits larger than 16k (actually somewhere between 16 and 32 k). I've added tests for this which pass in mysql but not in derby. Don't have a fix yet but the test are intermixed with the tests for the NOT NULL issue.
        Hide
        Stephen Bannasch added a comment -

        This patch is based of rev 879.

        It fixes the issues with my earlier patch.

        It also adds tests for a new problem – (text field limits don't work above some value larger than 16k) the new tests are in test/simple.rb where most of he other tests are located. So right now this patch fixes the issue in [JIRA-1905] and adds tests for a new issue.

        I'll make a new Jira issue for the new problem and continue work there.

        Show
        Stephen Bannasch added a comment - This patch is based of rev 879. It fixes the issues with my earlier patch. It also adds tests for a new problem – (text field limits don't work above some value larger than 16k) the new tests are in test/simple.rb where most of he other tests are located. So right now this patch fixes the issue in [JIRA-1905] and adds tests for a new issue. I'll make a new Jira issue for the new problem and continue work there.
        Hide
        Stephen Bannasch added a comment -

        The new tests for limit are still wrong ;-(
        fixing them

        Show
        Stephen Bannasch added a comment - The new tests for limit are still wrong ;-( fixing them
        Hide
        Charles Oliver Nutter added a comment -

        Looks like this could be close to done, so marking it for 1.1.2. Stephen, can you help us shove this one through?

        Show
        Charles Oliver Nutter added a comment - Looks like this could be close to done, so marking it for 1.1.2. Stephen, can you help us shove this one through?
        Hide
        Stephen Bannasch added a comment -

        I'll update to the latest jdbc code and check.

        Show
        Stephen Bannasch added a comment - I'll update to the latest jdbc code and check.
        Hide
        Thomas E Enebo added a comment -

        How we doing on this? Technically this should not hold up 1.1.2, but it would be nice to have AR-JDBC have a new version with this fix in it...

        Show
        Thomas E Enebo added a comment - How we doing on this? Technically this should not hold up 1.1.2, but it would be nice to have AR-JDBC have a new version with this fix in it...
        Hide
        Stephen Bannasch added a comment -

        adds a test which adds a 32k :text column to entries, attempts to fix problem for derby (not working yet), also hsqldb not working with a different error than derby

        Show
        Stephen Bannasch added a comment - adds a test which adds a 32k :text column to entries, attempts to fix problem for derby (not working yet), also hsqldb not working with a different error than derby
        Hide
        Stephen Bannasch added a comment -

        Wanted you to know I was working on this.

        Am having some trouble fixing the problems.

        Latest patch applies to latest svn (r1001). It adds a test which tries to make a 40k :text column.

        There is an attempted fix for derby which isn't working yet (see error below). Also hsqldb is not passing the test (also see error below).

        in derby (value for inserted text field below is truncated for this comment) :

        ActiveRecord::StatementInvalid: ActiveRecord::ActiveRecordError: 
          A string constant starting with ''...........................................................&' is too long.: 
          INSERT INTO entries (body, content, rating, title, updated_on) VALUES(CAST('... ...' AS CLOB), NULL, NULL, NULL, '2008-05-26 03:10:31')
        

        In hsqldb

        ActiveRecord::StatementInvalid: ActiveRecord::ActiveRecordError: 
          Unexpected token in statement [ALTER TABLE entries ADD body longvarchar(40000]: ALTER TABLE entries ADD body longvarchar(40000)
        

        "ALTER TABLE entries ADD body longvarchar(40000)" certainly looks to be perfectly legal SQL for hsqldb.

        I'll keep looking into the problem ... any ideas would be appreciated.

        Show
        Stephen Bannasch added a comment - Wanted you to know I was working on this. Am having some trouble fixing the problems. Latest patch applies to latest svn (r1001). It adds a test which tries to make a 40k :text column. There is an attempted fix for derby which isn't working yet (see error below). Also hsqldb is not passing the test (also see error below). in derby (value for inserted text field below is truncated for this comment) : ActiveRecord::StatementInvalid: ActiveRecord::ActiveRecordError: A string constant starting with ''...........................................................&' is too long .: INSERT INTO entries (body, content, rating, title, updated_on) VALUES(CAST('... ...' AS CLOB), NULL, NULL, NULL, '2008-05-26 03:10:31') In hsqldb ActiveRecord::StatementInvalid: ActiveRecord::ActiveRecordError: Unexpected token in statement [ALTER TABLE entries ADD body longvarchar(40000]: ALTER TABLE entries ADD body longvarchar(40000) "ALTER TABLE entries ADD body longvarchar(40000)" certainly looks to be perfectly legal SQL for hsqldb. I'll keep looking into the problem ... any ideas would be appreciated.
        Hide
        Stephen Bannasch added a comment -

        Ooops, last two comments and attachment should be for [JRUBY--1960]. I'll add the comments and patch there.

        I'll take a look at this problem again too.

        Show
        Stephen Bannasch added a comment - Ooops, last two comments and attachment should be for [JRUBY--1960] . I'll add the comments and patch there. I'll take a look at this problem again too.
        Hide
        Charles Oliver Nutter added a comment -

        Hmm, so this one still seems to be dragging on. Stephen: your last comment says you'd take a look at this again...have you been able to? This bug seems to have gotten a bit drawn out, so perhaps we should file a new bug for the new breakage that resulted after your set of patches. If you need help, maybe we can get a demo app set up or work through it on IRC. I hate to see bugs drag on so long and have so much work done, but not quite there yet. What can we do to move this one forward?

        Show
        Charles Oliver Nutter added a comment - Hmm, so this one still seems to be dragging on. Stephen: your last comment says you'd take a look at this again...have you been able to? This bug seems to have gotten a bit drawn out, so perhaps we should file a new bug for the new breakage that resulted after your set of patches. If you need help, maybe we can get a demo app set up or work through it on IRC. I hate to see bugs drag on so long and have so much work done, but not quite there yet. What can we do to move this one forward?
        Hide
        Charles Oliver Nutter added a comment -

        Very old, partial fixes in place, ar-jdbc has had many releases since, and this bug should go there anyway.

        Show
        Charles Oliver Nutter added a comment - Very old, partial fixes in place, ar-jdbc has had many releases since, and this bug should go there anyway.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Stephen Bannasch
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: