Than it's a bug, file an issue on google code. For the time being just copy
the table_archive .table file from the 1st app to the second one in the
databases/ folder.
I don't have the time to provide a patch but poking around the code in
dal.py the _enable_record_versioning() method doesn't "propagate" the
migrate attribute of the parent table.
.....
archive_db.define_table(
archive_name,
Field(current_record,field_type),
*[field.clone(unique=False) for field in self])
....
Don't know if it's a design decision or not, but stating that a table with
migrate=False doesn't need the creation of the relative "version" table
should be a valid point (i.e. users are required to enable record
versioning first and then set migrate=False and forget about both the
original and the "version" table)
On Monday, December 10, 2012 9:15:16 PM UTC+1, Cliff Kachinske wrote:
>
> 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?
>>>
>>
--
