Niphlod,
It still tries to define the table even if migrate is False.
There is code something like this in the shared tables:
init_migrate = True
if request.application != 'init':
init_migrate = False
db.define_table('attachments' .....,
migrate=init_migrate
)
On Monday, December 10, 2012 2:53:33 PM UTC-5, Niphlod wrote:
>
> does setting migrate=False in the 2nd app (recommended method) trigger the
> table definition ?
>
>
> On Monday, December 10, 2012 8:08:18 PM UTC+1, Cliff Kachinske wrote:
>>
>> I have several applications that share tables. One such is called
>> "attachments."
>>
>> As part of my upgrade to 2.2.1, I enabled record versioning in each of
>> these apps. I have a specific sequence for opening appadmin in these
>> applications to migrate the tables in case of changes.
>>
>> When I migrated the first application, it created the archive table for
>> attachments. So far, so good.
>>
>> When I attempted to migrate the second application, it also attempted to
>> create the archive table for attachments. Because the table already
>> exists, Psycopg2 raised an exception, 'relation "attachments_archive"
>> already exists.'
>>
>> Is there a way to avoid this?
>>
>> Would it make sense to have tools.enable_record_versioning or
>> dal._enable_record_versioning check for the existence of the archive table
>> before trying to create it?
>>
>
--
