db.define_table('page', ...
Field('created_by', authdb.auth_user)
you cannot reference a table in authdb from a different database db.
You can at the web2py level but not at the database level (since they
are different). At the web2py level you would do
db.define_table('page', ...
Field('created_by',
'integer',requires=IS_IN_DB(authdb,'auth_user.id'))
This will work except for the auth.accessible function.
On May 30, 1:27 pm, Doug Warren <doug.war...@gmail.com> wrote:
> Greetings,
>
> I'm testing how/if web2py could support foreign keys across db connections
>
> For example I modified the mywiki app to look like:
> db = DAL('sqlite://storage.sqlite')
> authdb = DAL('sqlite://authdb.sqlite')
>
> from gluon.tools import *
> auth=Auth(globals(),authdb) # authentication/authorization
> crud=Crud(globals(),authdb) # for CRUD helpers using auth
> ....
> auth.define_tables()
>
> db.define_table('page',
> Field('title'),
> Field('body', 'text'),
> Field('created_on', 'datetime', default=request.now),
> Field('created_by', authdb.auth_user, default=user_id))
>
> However, this causes an error:
> Traceback (most recent call last):
> File "gluon/restricted.py", line 178, in restricted
> File "C:/web2py/applications/mywiki/models/db.py", line 82, in <module>
> File "gluon/sql.py", line 1304, in define_table
> File "gluon/sql.py", line 1576, in _create_references
> SyntaxError: Table: table "auth_user" does not exist
>
> Thinking about it some I guess it makes sense but is there a standard way to
> support web2py having one centralized auth database for multiple
> applications and specific multiple instances of the same application? The
> use case that I'm considering is that of a game server. There's a single
> account login that supports Customer Support, CMS forums, as well as 15 game
> shards. Each shard has it's own game object database that's not shared with
> the other 14, however account data is shared across all apps and all
> instances of all apps. For the sake of fault tolerance, I'd like to isolate
> each application to it's own VM where the failure of one VM would not affect
> the failure of the others (Other than of course the case of the authdb being
> completely off line.)
