{5} Accepted, Active Tickets by Owner (Full Description) (17 matches)

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

andrew (17 matches)

Ticket Summary Component Milestone Type Created
Description
#32 ContentType table is not updated when renaming table migrations The Future defect 10/21/08

When a table is renamed, the ContentType? table is not updated, causing existing generic relations to fail.

#87 migrating models from an abstract model class commands The Future defect 02/27/09

Hi Fellows,

Commendations upon South, I LOVE IT.

However, I had no luck with adding a column to the base abstract model class, of which there are three slightly different inherited model classes.

Does it work?

#994 add_column(PositiveIntegerField, keep_default=False) create greater zero constraint twice commands 1.0 defect 01/16/12

If you use keep_default=False for add_column of a PositiveIntegerField?, the check constraint gets created twice.

You can reproduce it like this: Modify tests/db.py 

diff -r 2f9a84a48350 south/tests/db.py
--- a/south/tests/db.py	Fri Jan 13 13:34:00 2012 +0000
+++ b/south/tests/db.py	Mon Jan 16 16:56:47 2012 +0100
@@ -258,6 +258,14 @@
         val = db.execute("SELECT user_id FROM test_addc")[0][0]
         self.assertEquals(val, None)
         db.delete_column("test_addc", "add1")
+
+        db.add_column("test_addc", "num_positive", models.PositiveIntegerField(default=0), keep_default=False)
+        db.commit_transaction()
+        db.start_transaction()
+        import sys
+        print 'Inspect DB now. For postgres psql test_.... \d test_addc'
+        sys.stdin.readline()
+
         db.delete_table("test_addc")
 
     def test_add_nullbool_column(self):

Inspect the db before while scripts waits for input: 

Check-Constraints:
    "ck_num_positive_pstv_2ef4ccd14d7211b6" CHECK (num_positive >= 0)
    "test_addc_num_positive_check" CHECK (num_positive >= 0)

If you don't supply keep_default=False, then there is only one constraint.

Versions: 

PostgreSQL 8.4.8 on x86_64-unknown-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292], 64-bit

Python 2.6
#1024 retry_failed_fields methods fails to produce meaningfull error if exception message contains unicode chars commands 1.0 defect 02/05/12

Method south.orm.FakeOrm.retry_failed_field fails to produce meaningfull error if field raises exception that contains unicode chars during creation.

Faulty code is 

   try:
       field = self.eval_in_context(code, app, extra_imports)
   except (NameError, AttributeError, AssertionError, KeyError), e:
       # It's failed again. Complain.
       raise ValueError("Cannot successfully create field '%s' for model '%s': %s." % (
           fname, modelname, e
       ))

You should either use unicode pattern: 

raise ValueError(u"Cannot successfully create field '%s' for model '%s': %s." % (
           fname, modelname, e
       ))

or use repr: 

raise ValueError(u"Cannot successfully create field '%s' for model '%s': %s." % (
           fname, modelname, repr(e)
       ))

Full stack trace: 

Traceback (most recent call last):
  File "/home/jb/ides/pycharm-2.0.1/helpers/pydev/pydevd.py", line 1325, in <module>
    debugger.run(setup['file'], None, None)
  File "/home/jb/ides/pycharm-2.0.1/helpers/pydev/pydevd.py", line 1033, in run
    pydev_imports.execfile(file, globals, locals) #execute the script
  File "/home/jb/programs/drat/hajmon/hajmondjango/manage.py", line 15, in <module>
    execute_manager(settings)
  File "/usr/lib/python2.6/dist-packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/usr/lib/python2.6/dist-packages/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.6/dist-packages/django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.6/dist-packages/django/core/management/base.py", line 220, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/management/commands/migrate.py", line 105, in handle
    ignore_ghosts = ignore_ghosts,
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/__init__.py", line 191, in migrate_app
    success = migrator.migrate_many(target, workplan, database)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 221, in migrate_many
    result = migrator.__class__.migrate_many(migrator, target, migrations, database)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 292, in migrate_many
    result = self.migrate(migration, database)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 125, in migrate
    result = self.run(migration)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 93, in run
    south.db.db.current_orm = self.orm(migration)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 246, in orm
    return migration.orm()
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/utils.py", line 62, in method
    value = function(self)
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/base.py", line 422, in orm
    return FakeORM(self.migration_class(), self.app_label())
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py", line 46, in FakeORM
    _orm_cache[args] = _FakeORM(*args)  
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py", line 132, in __init__
    self.retry_failed_fields()
  File "/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py", line 371, in retry_failed_fields
    fname, modelname, e
#1049 unique_together ordering commands 1.0 defect 03/05/12

I am trying to add a unique_together constraint to a table.

The fields are listed in specific order, because the index that is created will perform properly only if the fields are in that order. So South needs to respect the order given in each tuple.

The fields are coming out in the right order in the freezer, so it must be something after that I guess (changes.py?).

#1073 South does not notice when a ForeignKey's type should change commands The Future defect 05/04/12

If I create ModelA which has a primary key set to a CharField?, and create a ForeignKey? from ModelB to ModelA, this works fine.

If I then change the ForeignKey? to ModelC, which has an integer primary key, but I don't rename the foreign key field, south doesn't notice.

#580 Converting from abstract class inheritance to multi-table inheritance commands The Future enhancement 09/14/10

It would be great if it were possible to convert an abstract base class to a concrete class with its own table (Removing abstract = True from a base class).

#579 Field name not updated on ManyToMany through table migrations 1.0 defect 09/13/10

I changed the model that a ManyToMany? field pointed to after the 'through' table already existed and deleted the old model. The through table field name still reflects the name of the old model even after schema migration. Opening the migrations before and after the change, I see that the variable models has been updated to reflect the change. Adding a list of model objects to the ManyToMany? field will fail because Django will expect the field name in the 'through' table to be that of the new model, and you get an error like:

_mysql_exceptions.OperationalError? OperationalError?: (1054, "Unknown column 'user_id' in 'field list'")

Thanks!

#958 Django-south test management commands breaks ability to use Nose coverage options commands 1.0 defect 11/21/11

Howdy,

Just run into a problem where after installing South I was no longer to run my unit tests through the Django test management command and still use the most excellent coverage package. Specifically, trying to run:

% python manage.py test --with-coverage

Would fail, saying that --with-coverage was an unknown option.

Some digging around leads to a rabbit hole of South and Nose both overloading each other, but ultimately comes down to the option_list for the command not including extra options from a custom TestRunner?. (Nose's test runner in this case)

In any case, for my install I fixed it by overloading the test management command yet again, in the same manner Nose does, to a sum total of the code below. This seems to play nicely regardless of which test runner is being used.

Hope it helps,

Cheers,

-Nic

from django.core.management.commands import test from south.management.commands import patch_for_test_db_setup from django.test.utils import get_runner from django.conf import settings

TestRunner? = get_runner(settings)

if hasattr(TestRunner?, 'options'):

extra_options = TestRunner?.options

else:

extra_options = []

class Command(test.Command):

option_list = test.Command.option_list + tuple(extra_options)

def handle(self, *args, kwargs):

patch_for_test_db_setup() super(Command, self).handle(*args, kwargs)

#992 Primary Key: SlugField to CharField migrations 1.0 defect 01/13/12

I changed a SlugField? to CharField? of a primary key. 

# models.py
  class EmailSender(models.Model):
-    id=models.SlugField(primary_key=True)
+    id=models.CharField(primary_key=True, max_length=50, validators=[RegexValidator(r'^[a-zA-Z0-9_.-]+$')])

The migration created with --auto looks like this: 

#migration
class Migration(SchemaMigration):

     def forwards(self, orm):

         # Changing field 'EmailSender.id'
         db.alter_column('modwork_emailsender', 'id', self.gf('django.db.models.fields.CharField')(max_length=50,
primary_key=True))

         # Removing index on 'EmailSender', fields ['id']
         db.delete_index('modwork_emailsender', ['id'])

{{{ psql \d modwork_emailsender modwork_tbz_d=> \d modwork_emailsender

Table "public.modwork_emailsender"

Column | Type | Modifiers

id | character varying(50) | not null email | character varying(75) | not null footer | text |

Indexes:

"modwork_emailsender_pkey" PRIMARY KEY, btree (id) "modwork_emailsender_email_uniq" UNIQUE, btree (email)

}}}

2012-01-13 10:04:36 generic: DEBUG south execute "DROP INDEX "modwork_emailsender_id"" with params "[]" django.db.utils.DatabaseError?: ERROR: Index »modwork_emailsender_id« does not exist

I removed the "delete_index()" and the migration was successfull.

south version: 

hg summary
parent: 997:fcf464bd036f tip
 Fixed the timezone handling by simply converting the timezone aware datetime object into a naive version with the help of the default timezone (aka settings.TIME_ZONE).
branch: default
commit: 1 unknown (clean)
update: (current)

Related: ​http://groups.google.com/group/south-users/browse_thread/thread/90ca1d17285df720/33b1c6233f06f1c8?show_docid=33b1c6233f06f1c8

#1050 converstion of IntegerField to PositiveIntegerField has constraint problems migrations 1.0 defect 03/05/12

I had an IntegerField? that I converted to a PositiveIntegerField?, the auto detector sees the change and makes some SQL changes that are over my head, so I'm not sure exactly what it is attempting to do, but the end result upon inspecting the database is that there is no constraint in place.

If I create a new PositiveIntegerField?, the column created is "integer" (in my case NOT NULL), the constraint is "fieldname >= 0". If I create an IntegerField? and convert it to a PositiveIntegerField? no constraint shows up.

Running on South 0.7.3, using Postgres 9.1, Django 1.3.

Output from running migration is:

execute: south execute "

SELECT kc.constraint_name, kc.column_name FROM information_schema.constraint_column_usage AS kc JOIN information_schema.table_constraints AS c ON

kc.table_schema = c.table_schema AND kc.table_name = c.table_name AND kc.constraint_name = c.constraint_name

WHERE

kc.table_schema = %s AND kc.table_name = %s AND c.constraint_type = %s

" with params "['public', 'proxy_rule', 'CHECK']"

execute: south execute "

SELECT kc.constraint_name, kc.column_name FROM information_schema.key_column_usage AS kc JOIN information_schema.table_constraints AS c ON

kc.table_schema = c.table_schema AND kc.table_name = c.table_name AND kc.constraint_name = c.constraint_name

WHERE

kc.table_schema = %s AND kc.table_name = %s AND c.constraint_type = %s

" with params "['public', 'proxy_rule', 'FOREIGN KEY']"

execute: south execute "ALTER TABLE "proxy_rule" ALTER COLUMN "testagain" TYPE integer, ALTER COLUMN "testagain" SET NOT NULL, ALTER COLUMN "testagain" DROP DEFAULT;" with params "[]"

In above, the "testagain" is the field I converted.

#1076 MySQL: delete_unique() fails if the index "supports" a FK migrations 1.0 defect 05/09/12

I'll paraphrase a mail I recently sent to the transifex-devel list

In (at least) MySQL 5.0.x and 5.1.x, foreign keys need to be "supported" by an index. If the user explicitly adds an index, MySQL will use that one. MySQL will not allow the index to be dropped. This is a problem for the following automatically-generated migration:

(Ref: ​https://github.com/transifex/transifex/blob/1.2/transifex/addons/webhooks/migrations/0002_allow_many_hooks_to_a_project.py) 

def forwards(self, orm):
    # Removing unique constraint on 'WebHook', fields ['project']
    db.delete_unique('webhooks_webhook', ['project_id'])

    # Changing field 'WebHook.project'
    db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))

The call to delete_unique() causes a mysterious MySQL error (I believe they have changed it to something more user-friendly in later releases): 

  _mysql_exceptions.OperationalError: (1025, "Error on rename of '.\\tfex\\#sql-27f0_16' to '.\\tfex\\webhooks_webhook' (errno: 150)")

One fix for transifex is to hand-modify the migration like so: 

    def forwards(self, orm):
       
        # Removing unique constraint on 'WebHook', fields ['project']
+       # Remove the foreign key to avoid problems with MySQL; it'll get recreated.
+       db.delete_foreign_key('webhooks_webhook', 'project_id')
        db.delete_unique('webhooks_webhook', ['project_id'])

        # Changing field 'WebHook.project'
        db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))

I suppose another possiblity is for MySQL's delete_unique to get a little smarter.

#1109 m2m tables greted twice commands The Future defect 06/06/12

This creates the m2m table twice.

This is idiomatic if you want the relation to show up bidirectionally in the admin or in autogenerated forms; cf. ​https://code.djangoproject.com/ticket/897 

class Test1(models.Model):
    tests2 = models.ManyToManyField('Test2', blank=True)

class Test2(models.Model):
    tests1 = models.ManyToManyField(Test1, through=Test1.tests2.through, blank=True)
#932 Support for insert+select databaseapi The Future enhancement 10/14/11

There should be a function/abstraction for doing large scale data migrations that can be implemented as 'insert into ... select ...'

Currently doing this with ORM layer is inadvisable as this constructs many objects, runs out of memory quickly and takes forever to run. In comparison the corresponding insert+select query completes in a few seconds.

#930 define Command.args for schemamigration documentation 1.0 enhancement 10/02/11

Currently, "./manage.py help schemamigration" shows a generic usage string: 

Usage: manage.py schemamigration [options]

It would be really great for this to look closer to the usage string shown when if you enter "./manage.py schemamigration": 

Usage: ./manage.py schemamigration appname migrationname [--empty] [--initial] [--auto] [--add-model ModelName] [--add-field ModelName.field_name] [--stdout]

At a minimum setting Command.args = "<appname migrationname>" would help newbies realize that you can actually pass a custom migration name. (This is not mentioned in the introductory documentation, and the output of "./migrate.py help schemamigration" does not mention args at all.)

#956 Fixtures from migrations - add warning documentation 1.0 enhancement 11/17/11

Hi,

The recommended way to load fixtures is to

call_command("loaddata", "my_fixture.json")

described in the docs:

http://south.aeracode.org/docs/fixtures.html#fixtures-from-migrations

The only problem is that loaddata will not throw exceptions on any error that might occur while loading the data (ex. invalid json, referential integrity errors etc.) It will print out the stack trace to sys.err and return without throwing an exception. South has no way of knowing that there were any errors and will think that the migration applied cleanly and will mark it so.

I don't think there is much you can do without changing Django, but I think it would be nice to at least add a warning to the docs so people are aware of the problem and can deal with it.

(We have a Django fork so patched loaddata to throw exceptions if an extra option is passed in. Our call_command became:

call_command("loaddata", "my_fixture.json", exceptiononerror = True) )

Thanks

#1140 Additional error handling for 'app' argument commands The Future enhancement 07/23/12

When specifying the app argument while creating a schemamigration, I spent a bit of time futzing because I had a '/' at the end of the argument which gave me an ambiguous error message.

It would have been nice if there was something like:

if <app> and app[-1] == '/':

raise Exception("You must specify the app name, not it\'s location. Try removing '
' from the app )name.\n"

in place to catch this.

Thanks for having a form to create tickets for suggestions.

Note: See TracReports for help on using and creating reports.