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

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

andrew (12 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
#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).

#578 Boolean default values are not set correctly when adding new columns with sqlite databaseapi 1.0 defect 09/10/10

If you add a new BooleanField to a model, with default=True in a SQLite database, the column will be filled with 'True' strings after migration, and that won't be interpreted as True booleans in Django.

This is because SQLite doesn't have a boolean type, and Django expects booleans to be stored as '1' or '0' in SQLite databases. The problem is specific to SQLite, other database backends recognize "DEFAULT True" properly as a boolean value.

To fix this we need some sort of database-specific mechanism to transform Python values to their SQL representation. Attached is a patch with a suggestion of API to do this properly, and the fix for this particular SQLite problem.

Note: the patch also uses django's Field.get_db_prep_save() method to transform the default values to their database representation, which I believe is the correct way to process values before passing them to the database layer.

#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

#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

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