составной ключ в web2py

Это зависит от того, что вы пытаетесь сделать. По умолчанию web2py автоматически создает поле id с автоматическим увеличением, которое служит первичным ключом для каждой таблицы, и это рекомендуемый подход, когда это возможно. Если вы имеете дело с устаревшей базой данных с составными первичными ключами и не можете изменить схему, вы можете указать атрибут primarykey, хотя и с некоторыми ограничениями (как объяснено здесь):

db.define_table('pairing', 
    Field('user', writable=True, readable=True), 
    Field('uid', writable=True, readable=True),
    primarykey=['user', 'uid'])

Возможно, вместо этого вам действительно не нужен настоящий составной первичный ключ, но вам просто нужен какой-то способ гарантировать, что в таблицу будут вставлены только уникальные пары значений user/uid. В этом случае вы можете сделать это, указав правильно сконструированный IS_NOT_IN_DB валидатор для одного из двух полей:

db.define_table('pairing',
    Field('user', writable=True, readable=True),
    Field('uid', writable=True, readable=True))

db.pairing.uid.requires=IS_NOT_IN_DB(db(db.pairing.user==request.vars.user),
    'pairing.uid')

Это обеспечит уникальность uid среди набора записей, где user соответствует новому вставляемому значению user (поэтому комбинация user и uid должна быть уникальной). Обратите внимание, что валидаторы (такие как IS_NOT_IN_DB) применяются только тогда, когда значения вставляются с помощью метода SQLFORM или с использованием метода .validate_and_insert(), поэтому описанное выше не будет работать для произвольных вставок в таблицу, но в первую очередь предназначено для ввода данных пользователем.

Вы также можете использовать SQL, чтобы установить уникальное ограничение для нескольких столбцов в таблице (что вы можете сделать непосредственно в базе данных или с помощью метода web2py .executesql()). Однако даже с таким ограничением вы все равно захотите выполнить некоторую проверку ввода в своем приложении, чтобы избежать ошибок в базе данных.

Я использую вычисляемое поле для создания/моделирования составного ключа. Взяв пример из приведенного выше вопроса, можно определить таблицу соединений следующим образом:

from md5 import md5
db.define_table( 'pairing',
                 Field('user', writable=True, readable=True),
                 Field('uid', writable=True, readable=True),
                 Field( 'user_uid_md5', 
                        length=32,
                        unique=True,
                        writable=False,
                        readable=False,
                        compute=lambda row: md5("{0}:{1}".format(row.user,row.uid)).hexdigest()))

Поле user_uid_md5 автоматически вычисляется при вставке и обновлении. Значение этого поля представляет собой md5 хэш строки, полученной из двух полей user и uid. . Это поле также помечено как unique. Таким образом, база данных обеспечивает здесь уникальность, и это работает в обход ограничения, указанного Энтони. Это также должно работать для эмуляции составных ключей с более чем двумя полями. Если вы видите какие-либо пробелы в этом подходе, пожалуйста, дайте мне знать.

Изменить: небольшое обновление способа вычисления хэша md5 для учета случая, указанного Chen Levy в комментарий ниже.