Sphene Community Tools

In attempting to upgrade to Sphene 0.5, we've run into some problems with the forums. It works with a fresh DB, but upgrading from a DB with Sphene 0.4 causes table errors whenever you try to access the forum. The full error report is located here, but the relevant line (I think) is:

ProgrammingError: column community_communityuserprofile.displayname does not exist

Were the tables for Sphene updated in 0.5, and if so, what's the best method to get tables from 0.4 working with 0.5? I gather that syncdb won't work, since it only creates new tables, and doesn't alter old ones.

please try a syncdb ... i'm using a very simple changelog mechanism which should apply all database changes..

let me know if it works for you :)

Apparently that is not enough to do the job:

python manage.py syncdb
/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/__init__.py:7: DeprecationWarning: django.newforms is no longer new. Import django.forms instead.
from django import newforms as djangoforms
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 340, in execute_manager
utility.execute()
File "/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 295, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.5/site-packages/django/core/management/base.py", line 192, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.5/site-packages/django/core/management/base.py", line 210, in execute
translation.activate('en-us')
File "/usr/local/lib/python2.5/site-packages/django/utils/translation/__init__.py", line 73, in activate
return real_activate(language)
File "/usr/local/lib/python2.5/site-packages/django/utils/translation/__init__.py", line 43, in delayed_loader
return g['real_%s' % caller](*args, **kwargs)
File "/usr/local/lib/python2.5/site-packages/django/utils/translation/trans_real.py", line 209, in activate
_active[currentThread()] = translation(language)
File "/usr/local/lib/python2.5/site-packages/django/utils/translation/trans_real.py", line 198, in translation
default_translation = _fetch(settings.LANGUAGE_CODE)
File "/usr/local/lib/python2.5/site-packages/django/utils/translation/trans_real.py", line 181, in _fetch
app = getattr(__import__(appname[:p], {}, {}, [appname[p+1:]]), appname[p+1:])
File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/__init__.py", line 11, in <module>
from sphene.community.sphutils import get_sph_setting
File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/sphutils.py", line 6, in <module>
from sphene.community.middleware import get_current_request, get_current_sphdata
File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/middleware.py", line 5, in <module>
from sphene.community.models import Group
File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/models.py", line 44, in <module>
class GroupMember(models.Model):
File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/models.py", line 45, in GroupMember
group = models.ForeignKey( Group, edit_inline = models.TABULAR, core = True )
AttributeError: 'module' object has no attribute 'TABULAR'

This is also what happens when I try to restart the server.

Dave, did we revert to an earlier version of Sphene? That code is definitely not in Sphene 0.5, which is probably the cause of the 500 internal server errors we've been getting.

Yes, administrator error was holding back our version of the Sphene source on the server. But now that that's handled, I may have caused sphene to think the database is updated even though it really isn't. I say that because there was an error the first time I tried to do it, and the next time around it apparently thought there was nothing to do. I sure hope I'm mistaken, though. Herbert, can you offer any suggestions?

$ python manage.py syncdb
Creating table community_rolegroup
Creating table community_rolegroupmember
2008-04-06 00: SQL Statement: ALTER TABLE "community_groupmember" ADD userlevel integer
2008-04-06 01: SQL Statement: UPDATE "community_groupmember" SET userlevel = 0
2008-04-06 02: SQL Statement: ALTER TABLE "community_groupmember" ALTER userlevel SET NOT NULL
2008-04-10 00: SQL Statement: ALTER TABLE "community_communityuserprofile" ADD displayname varchar(250)
2008-04-10 01: SQL Statement: UPDATE "community_communityuserprofile" SET displayname = ''
2008-04-10 02: SQL Statement: ALTER TABLE "community_communityuserprofile" ALTER displayname SET NOT NULL
2008-04-15 00: SQL Statement: ALTER TABLE "community_rolemember" ALTER user_id DROP NOT NULL
2008-04-15 01: SQL Statement: ALTER TABLE "community_rolemember" ADD rolegroup_id integer REFERENCES community_rolegroup(id)
Detected changes - Do you want to execute SQL Statements ? (yes,no): yes
2008-03-23 00: SQL Statement: ALTER TABLE "sphwiki_wikisnipchange" ADD title VARCHAR(250)
2008-03-23 01: SQL Statement: UPDATE "sphwiki_wikisnipchange" SET title = ''
2008-03-23 02: SQL Statement: ALTER TABLE "sphwiki_wikisnipchange" ALTER title SET NOT NULL
2008-03-23 03: SQL Statement: ALTER TABLE "sphwiki_wikisnipchange" ADD change_type INTEGER
2008-03-23 04: SQL Statement: UPDATE "sphwiki_wikisnipchange" SET change_type = 0
2008-03-23 05: SQL Statement: ALTER TABLE "sphwiki_wikisnipchange" ALTER change_type SET NOT NULL
Detected changes - Do you want to execute SQL Statements ? (yes,no): yes
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 340, in execute_manager
    utility.execute()
  File "/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 295, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/base.py", line 192, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/base.py", line 219, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/base.py", line 348, in handle
    return self.handle_noargs(**options)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/commands/syncdb.py", line 101, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/usr/local/lib/python2.5/site-packages/django/core/management/sql.py", line 205, in emit_post_sync_signal
    interactive=interactive)
  File "/usr/local/lib/python2.5/site-packages/django/dispatch/dispatcher.py", line 148, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/usr/local/www/django/boostcon/boost_consulting/communitytools/sphenecoll/sphene/community/management.py", line 125, in do_changelog
    curs.execute( sqlstmt )
psycopg2.OperationalError: cannot ALTER TABLE "sphwiki_wikisnipchange" because it has pending trigger events

[dave@boost-consulting /usr/local/www/django/boostcon/boost_consulting]$ sudo /usr/local/etc/rc.d/django_boostcon stop 
Password:
Stopping django_boostcon FCGI processes
[dave@boost-consulting /usr/local/www/django/boostcon/boost_consulting]$ python manage.py syncdb
[dave@boost-consulting /usr/local/www/django/boostcon/boost_consulting]$ sudo /usr/local/etc/rc.d/django_boostcon start
Starting django_boostcon FCGI processes

i think the easiest fix would be to simply execute the SQL statements by hand which were displayed ..
you could modify the version in the database so a syncdb would execute it again .. but i see no benefit in doing so ..

OK, but it seems pretty clear to me that this is a bug in Sphene. If a database update fails it should not be marked as completed, should it?

The error:

cannot ALTER TABLE "sphwiki_wikisnipchange" because it has pending trigger events

seems to be a database integrity related issue. Which db backend are you using? And, is it possible that when you first did the update the db was in some kind of non-consistent state?

I am using psycopg2 (PostGreSQL). Of course anything is possible, but
I don't have any reason to believe there was any corruption, and
running the commands manually seems to have worked in the end (the
site works just fine now).

Hmmm...
So the pending trigger events were probably caused by something in the upgrade SQL statements that was submitted to the Db before the ALTER TABLE.

I'm planning a similar upgrade on a semi-test site, I'll see what happens if I get the time to work on it in these relatively work-free days :-) (semi-test: I've had too little time to work on it and it's basically empty)