Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #2382 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

Quickstarted TG 1.1 project with SO and identity throws OperationalError

Reported by: chrisz Owned by: Chris Arndt
Priority: high Milestone: 1.1
Component: TurboGears Version: 1.1 HEAD
Severity: blocker Keywords: sqlobject identity
Cc:

Description

Quickstarted a TG 1.1rc1 project with SQLObject (0.11.2, but the same happened with 0.10.1 and 0.10.2) and Identity. Created tables and added a user. Tried to log in as the user. Got the following error:

Traceback (most recent call last):
  File "...\cherrypy\_cphttptools.py", line 119, in _run
    applyFilters('before_main')
  File "...\cherrypy\filters\__init__.py", line 151, in applyFilters
    method()
  File "...\branches\1.1\turbogears\visit\api.py", line 256, in before_main
    plugin.record_request(visit)
  File "...\branches\1.1\turbogears\identity\visitor.py", line 183, in record_request
    identity = self.identity_from_request(visit.key)
  File "...\branches\1.1\turbogears\identity\visitor.py", line 94, in identity_from_request
    identity = source(visit_key)
  File "...\1.1\turbogears\identity\visitor.py", line 164, in identity_from_form
    identity = self.provider.validate_identity(user_name, pw, visit_key)
  File "...\branches\1.1\turbogears\identity\soprovider.py", line 223, in validate_identity
    user = user_class.by_user_name(user_name)
  File "<string>", line 1, in <lambda>
  File "...\sqlobject\main.py", line 1329, in _SO_fetchAlternateID
    result, obj = cls._findAlternateID(name, dbName, value, connection)
  File "...\sqlobject\inheritance\__init__.py", line 390, in _findAlternateID
    result = list(cls.selectBy(connection, **{name: value}))
  File "...\sqlobject\sresults.py", line 179, in __iter__
    return iter(list(self.lazyIter()))
  File "...\sqlobject\sresults.py", line 187, in lazyIter
    return conn.iterSelect(self)
  File "...\sqlobject\dbconnection.py", line 717, in iterSelect
    select, keepConnection=True)))
  File "...\sqlobject\inheritance\iteration.py", line 10, in __init__
    super(InheritableIteration, self).__init__(dbconn, rawconn, select, keepConnection)
  File "...\sqlobject\dbconnection.py", line 646, in __init__
    self.dbconn._executeRetry(self.rawconn, self.cursor, self.query)
  File "...\sqlobject\sqlite\sqliteconnection.py", line 183, in _executeRetry
    raise OperationalError(ErrorMessage(e))
OperationalError: no such column: tg_user.child_name

Did nobody try TG 1.1 with SQLObject? Why does our test suite not catch this?

Change History

comment:1 Changed 10 years ago by chrisz

I think this has something to do with the different definition of the model classes for users in the model.py template vs. soprovider.py.

The names of the classes differ (User vs TG_User), the base classes differ (SQLObject vs. InheritableSQLObject) and in the case of permissions, even the table name (permissions vs. tg_permissions). What a mess!

comment:2 Changed 10 years ago by chrisz

The main problem was that r6715 accidentally merged in the config settings for the sa provider instead of those for the so provider. That's why the default classes became active and they were incompatible with those of the quickstart model template. I fixed the bug and also made the default classes compatible with the quickstart model template in r6749.

comment:3 Changed 10 years ago by chrisz

  • Owner set to Chris Arndt

Just to clarify: The different class names (User vs TG_User) were by design, because SQLObject classes in the registry must have unique names. The different base class (SQLObject vs. InheritableSQLObject) caused the error because only the latter creates the "child_name" attribute. And some of the table names were the same, some not. I think they should either all be different, or all be the same. I chose the latter.

ChrisA, can you double check this and close the ticket if it's ok?

comment:4 Changed 10 years ago by Chris Arndt

  • Status changed from new to assigned
  • Version changed from 1.1rc1 to 1.1 HEAD

r6715 was committed post 1.1rc release, but good you caught that. I' sure I would have notice it when running the pre-release tests ;) , but better now then later. Sorry for the mix-up. I will check the fix later.

comment:5 Changed 10 years ago by Chris Arndt

  • Status changed from assigned to closed
  • Resolution set to fixed

Worksforme now. I think this would have been caught by the unit tests in the quickstart templates. I obviously did not run them before committing r6715, but I usually do before a release, so I think we don't need additional tests here.

Note: See TracTickets for help on using tickets.