Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Alex Glaros]

am a beginner and not sure if this suggestion makes sense

my restore/migrate/fake_migrate didn't work but everything else worked 
normally

I downloaded a new copy of web2py and everything now works flawlessly.  I 
already had the latest version and it was the same version as I already had 
but something was different about it.

Alex Glaros

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

Hmm... About app/databases/ I don't know exactly all how it works, but I
think your issue come form there... uuid if there is one, would not have
anything to do with your computer, I am pretty sure of that, and you can
leave these files there for sure without any problem...

Though there surely some kind of issue with migrate=False,
fake_migrate=True if it failed to manage archive tables correctly and sync
web2py with the backend schema... This is a corner case, that may not have
been identify yet... You may consider creating a dummy app and try to
reproduce the issue with this app and test it with last version of web2py
to see if issue still there (if any).

test case :

- at least 2 tables with web2py versionning
- versionning should occur in a unique table
- delete app/databases/*
- try fake_migrate see if it fails


If you can reproduce this issue, in you actual web2py version and in a new
version, then open a ticket on github... So we all get aware of this
issue...

Thanks

Richard


On Tue, Feb 23, 2016 at 6:26 PM, Brian M  wrote:

> The web2py version is the same on both machines; I just copied my whole
> web2py folder over. Now admittedly my web2py version is slightly out of
> date so it might be something that's been improved recently. I've got a
> patch for another issue that I need to pull and test tonight so I'll try to
> make a test for this too.
>
> The archive table was originally created by web2py.  Yes, I did delete
> .table files from /app/databases but they were the ones from the other
> computer (different uuid hash in file name) and weren't being used anyway
> so that shouldn't make a difference.
>
> On Tuesday, February 23, 2016 at 11:22:06 AM UTC-6, Richard wrote:
>>
>> Pretty weird, but you have made some progress... So, to resume, it like
>> if archive table were never really get created by web2py so it keeps trying
>> to create it and failed since it already exist in the backend...
>>
>> So, there were an issue at the moment you start using the feature, or
>> there is an error in the actual web2py version (did you upgrade web2py as
>> long as migrating you system??, if so consider use the old web2py to see if
>> the issue occuring... This would help determine if the issue is coming form
>> new web2py version or not).
>>
>> Or could it be possible that you create the archive table manually back
>> in time? Or that some file in app/databases/ folder get deleted??
>>
>> Richard
>>
>>
>>
>> On Tue, Feb 23, 2016 at 11:12 AM, Brian M  wrote:
>>
>>> Richard,
>>>
>>> Nope, I didn't change the name of the app itself. The only thing that
>>> changed is the name of the computer the DB is on and thus the DAL
>>> connection string.
>>>
>>> The traceback error is :
>>>  ('42S01', "[42S01] [Microsoft][SQL
>>> Server Native Client 11.0][SQL Server]There is already an object named
>>> 'shipment_at_risk_archive' in the database. (2714) (SQLExecDirectW)")
>>>
>>> Interestingly the error doesn't occur on every request even though the
>>> db.shipment_at_risk._enable_record_versioning() is in a plain model file
>>> and would presumably get executed for every page. It only pops up if I'm
>>> trying to get into the database admin screen of App Admin or if I'm on a
>>> page that actually utilizes the archive table.
>>>
>>> Attempting to include an archive_name matching the existing table within
>>> _enable_record_versioning() results in the same error. If I use a new name
>>> for the archive table then it just creates that table and works fine but
>>> this isn't desirable since I want to keep using the data in the
>>> pre-existing archive table. Having _enable_record_versioning() enabled for
>>> only a single table at a time also does no good.
>>>
>>> What I've ended up doing to get past this is using a different
>>> archive_name value and letting the DAL go ahead and create new tables. Then
>>> i just changed the database/ .table file's name to match the original
>>> archive table's name and also edited the contents so that it used the
>>> original table name in things like constraints.  That seems to work and is
>>> essentially doing a manual fake migration.  But I'd still like to hear from
>>> Massimo or another dev whether or not this is intended to behave this way
>>> or if there really should be a fake_migrate argument for
>>> _enable_record_versioning() like there is for regular table definitions.
>>>
>>> Brian
>>>
>>> On Monday, February 22, 2016 at 10:18:31 PM UTC-6, Richard wrote:

 Other possible explanation... Did you change app name? Sometimes this
 kind of web2py feature use some part of web2py and app three in the name of
 table created "automagically"...

 For instance... I was having issue with session in database feature
 because web2py use application name in the table name of the session in
 database feature, so if I was not specify the name of the table in which I
 want the session file to be store and I 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

The web2py version is the same on both machines; I just copied my whole 
web2py folder over. Now admittedly my web2py version is slightly out of 
date so it might be something that's been improved recently. I've got a 
patch for another issue that I need to pull and test tonight so I'll try to 
make a test for this too.

The archive table was originally created by web2py.  Yes, I did delete 
.table files from /app/databases but they were the ones from the other 
computer (different uuid hash in file name) and weren't being used anyway 
so that shouldn't make a difference.

On Tuesday, February 23, 2016 at 11:22:06 AM UTC-6, Richard wrote:
>
> Pretty weird, but you have made some progress... So, to resume, it like if 
> archive table were never really get created by web2py so it keeps trying to 
> create it and failed since it already exist in the backend... 
>
> So, there were an issue at the moment you start using the feature, or 
> there is an error in the actual web2py version (did you upgrade web2py as 
> long as migrating you system??, if so consider use the old web2py to see if 
> the issue occuring... This would help determine if the issue is coming form 
> new web2py version or not).
>
> Or could it be possible that you create the archive table manually back in 
> time? Or that some file in app/databases/ folder get deleted??
>
> Richard
>
>
>
> On Tue, Feb 23, 2016 at 11:12 AM, Brian M  > wrote:
>
>> Richard,
>>
>> Nope, I didn't change the name of the app itself. The only thing that 
>> changed is the name of the computer the DB is on and thus the DAL 
>> connection string.
>>
>> The traceback error is :
>>  ('42S01', "[42S01] [Microsoft][SQL 
>> Server Native Client 11.0][SQL Server]There is already an object named 
>> 'shipment_at_risk_archive' in the database. (2714) (SQLExecDirectW)")
>>
>> Interestingly the error doesn't occur on every request even though the 
>> db.shipment_at_risk._enable_record_versioning() is in a plain model file 
>> and would presumably get executed for every page. It only pops up if I'm 
>> trying to get into the database admin screen of App Admin or if I'm on a 
>> page that actually utilizes the archive table.
>>
>> Attempting to include an archive_name matching the existing table within 
>> _enable_record_versioning() results in the same error. If I use a new name 
>> for the archive table then it just creates that table and works fine but 
>> this isn't desirable since I want to keep using the data in the 
>> pre-existing archive table. Having _enable_record_versioning() enabled for 
>> only a single table at a time also does no good.
>>
>> What I've ended up doing to get past this is using a different 
>> archive_name value and letting the DAL go ahead and create new tables. Then 
>> i just changed the database/ .table file's name to match the original 
>> archive table's name and also edited the contents so that it used the 
>> original table name in things like constraints.  That seems to work and is 
>> essentially doing a manual fake migration.  But I'd still like to hear from 
>> Massimo or another dev whether or not this is intended to behave this way 
>> or if there really should be a fake_migrate argument for 
>> _enable_record_versioning() like there is for regular table definitions.
>>
>> Brian
>>
>> On Monday, February 22, 2016 at 10:18:31 PM UTC-6, Richard wrote:
>>>
>>> Other possible explanation... Did you change app name? Sometimes this 
>>> kind of web2py feature use some part of web2py and app three in the name of 
>>> table created "automagically"...
>>>
>>> For instance... I was having issue with session in database feature 
>>> because web2py use application name in the table name of the session in 
>>> database feature, so if I was not specify the name of the table in which I 
>>> want the session file to be store and I rename application (which I do in 
>>> order to test version tag and deploy) I wasn't able to execute tests 
>>> because web2py try to insert records in the wrong table... So I had to 
>>> specify table name like so :
>>>
>>> session.connect(request, response, db, masterapp='APP_NAME')
>>>
>>> So session goes in web2py_session_APP_NAME session for any clone of the 
>>> master app...
>>>
>>> Richard
>>>
>>>
>>> On Mon, Feb 22, 2016 at 11:09 PM, Richard Vézina  
>>> wrote:
>>>
 Ok, so in this case, my theory is good... Try to leave just one 
 _enable_record_versioning() for one turn... You try access your app with 
 only one table under record versioning to see if it works... Then if this 
 work, I would make sure (explicit) what is the name of the archive table 
 to 
 see if the issue go away...

 Richard

 On Mon, Feb 22, 2016 at 10:46 PM, Brian M  wrote:

> No, not using single archive table. For each table I want archiving 
> enabled for, fortunately only a few, I have 
> db.table_name1._enable_archiving(), 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

Pretty weird, but you have made some progress... So, to resume, it like if
archive table were never really get created by web2py so it keeps trying to
create it and failed since it already exist in the backend...

So, there were an issue at the moment you start using the feature, or there
is an error in the actual web2py version (did you upgrade web2py as long as
migrating you system??, if so consider use the old web2py to see if the
issue occuring... This would help determine if the issue is coming form new
web2py version or not).

Or could it be possible that you create the archive table manually back in
time? Or that some file in app/databases/ folder get deleted??

Richard



On Tue, Feb 23, 2016 at 11:12 AM, Brian M  wrote:

> Richard,
>
> Nope, I didn't change the name of the app itself. The only thing that
> changed is the name of the computer the DB is on and thus the DAL
> connection string.
>
> The traceback error is :
>  ('42S01', "[42S01] [Microsoft][SQL
> Server Native Client 11.0][SQL Server]There is already an object named
> 'shipment_at_risk_archive' in the database. (2714) (SQLExecDirectW)")
>
> Interestingly the error doesn't occur on every request even though the
> db.shipment_at_risk._enable_record_versioning() is in a plain model file
> and would presumably get executed for every page. It only pops up if I'm
> trying to get into the database admin screen of App Admin or if I'm on a
> page that actually utilizes the archive table.
>
> Attempting to include an archive_name matching the existing table within
> _enable_record_versioning() results in the same error. If I use a new name
> for the archive table then it just creates that table and works fine but
> this isn't desirable since I want to keep using the data in the
> pre-existing archive table. Having _enable_record_versioning() enabled for
> only a single table at a time also does no good.
>
> What I've ended up doing to get past this is using a different
> archive_name value and letting the DAL go ahead and create new tables. Then
> i just changed the database/ .table file's name to match the original
> archive table's name and also edited the contents so that it used the
> original table name in things like constraints.  That seems to work and is
> essentially doing a manual fake migration.  But I'd still like to hear from
> Massimo or another dev whether or not this is intended to behave this way
> or if there really should be a fake_migrate argument for
> _enable_record_versioning() like there is for regular table definitions.
>
> Brian
>
> On Monday, February 22, 2016 at 10:18:31 PM UTC-6, Richard wrote:
>>
>> Other possible explanation... Did you change app name? Sometimes this
>> kind of web2py feature use some part of web2py and app three in the name of
>> table created "automagically"...
>>
>> For instance... I was having issue with session in database feature
>> because web2py use application name in the table name of the session in
>> database feature, so if I was not specify the name of the table in which I
>> want the session file to be store and I rename application (which I do in
>> order to test version tag and deploy) I wasn't able to execute tests
>> because web2py try to insert records in the wrong table... So I had to
>> specify table name like so :
>>
>> session.connect(request, response, db, masterapp='APP_NAME')
>>
>> So session goes in web2py_session_APP_NAME session for any clone of the
>> master app...
>>
>> Richard
>>
>>
>> On Mon, Feb 22, 2016 at 11:09 PM, Richard Vézina 
>> wrote:
>>
>>> Ok, so in this case, my theory is good... Try to leave just one
>>> _enable_record_versioning() for one turn... You try access your app with
>>> only one table under record versioning to see if it works... Then if this
>>> work, I would make sure (explicit) what is the name of the archive table to
>>> see if the issue go away...
>>>
>>> Richard
>>>
>>> On Mon, Feb 22, 2016 at 10:46 PM, Brian M  wrote:
>>>
 No, not using single archive table. For each table I want archiving
 enabled for, fortunately only a few, I have
 db.table_name1._enable_archiving(), db.table_name2._enable_archiving() and
 my database does that have separate tables for table_name1_archive and
 table_name2_archive.  I'm pretty sure that by default if you haven't
 explicitly provides some other name for the archive table web2py
 automatically uses _archive which is exactly what I have
 (because _enable_record_versioning() initially created the tables in the
 database I restored from)

 On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:
>
> I think it because you use single archive table, could it be??
>
> If I remember there is many differents way to setup record versioning
> feature...
>
> So what may happen in your case, if you have a single history table
> and multiple ._enable_record_versing() for 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

Richard,

Nope, I didn't change the name of the app itself. The only thing that 
changed is the name of the computer the DB is on and thus the DAL 
connection string.

The traceback error is :
 ('42S01', "[42S01] [Microsoft][SQL Server 
Native Client 11.0][SQL Server]There is already an object named 
'shipment_at_risk_archive' in the database. (2714) (SQLExecDirectW)")

Interestingly the error doesn't occur on every request even though the 
db.shipment_at_risk._enable_record_versioning() is in a plain model file 
and would presumably get executed for every page. It only pops up if I'm 
trying to get into the database admin screen of App Admin or if I'm on a 
page that actually utilizes the archive table.

Attempting to include an archive_name matching the existing table within 
_enable_record_versioning() results in the same error. If I use a new name 
for the archive table then it just creates that table and works fine but 
this isn't desirable since I want to keep using the data in the 
pre-existing archive table. Having _enable_record_versioning() enabled for 
only a single table at a time also does no good.

What I've ended up doing to get past this is using a different archive_name 
value and letting the DAL go ahead and create new tables. Then i just 
changed the database/ .table file's name to match the original archive 
table's name and also edited the contents so that it used the original 
table name in things like constraints.  That seems to work and is 
essentially doing a manual fake migration.  But I'd still like to hear from 
Massimo or another dev whether or not this is intended to behave this way 
or if there really should be a fake_migrate argument for 
_enable_record_versioning() like there is for regular table definitions.

Brian

On Monday, February 22, 2016 at 10:18:31 PM UTC-6, Richard wrote:
>
> Other possible explanation... Did you change app name? Sometimes this kind 
> of web2py feature use some part of web2py and app three in the name of 
> table created "automagically"...
>
> For instance... I was having issue with session in database feature 
> because web2py use application name in the table name of the session in 
> database feature, so if I was not specify the name of the table in which I 
> want the session file to be store and I rename application (which I do in 
> order to test version tag and deploy) I wasn't able to execute tests 
> because web2py try to insert records in the wrong table... So I had to 
> specify table name like so :
>
> session.connect(request, response, db, masterapp='APP_NAME')
>
> So session goes in web2py_session_APP_NAME session for any clone of the 
> master app...
>
> Richard
>
>
> On Mon, Feb 22, 2016 at 11:09 PM, Richard Vézina  > wrote:
>
>> Ok, so in this case, my theory is good... Try to leave just one 
>> _enable_record_versioning() for one turn... You try access your app with 
>> only one table under record versioning to see if it works... Then if this 
>> work, I would make sure (explicit) what is the name of the archive table to 
>> see if the issue go away...
>>
>> Richard
>>
>> On Mon, Feb 22, 2016 at 10:46 PM, Brian M > > wrote:
>>
>>> No, not using single archive table. For each table I want archiving 
>>> enabled for, fortunately only a few, I have 
>>> db.table_name1._enable_archiving(), db.table_name2._enable_archiving() and 
>>> my database does that have separate tables for table_name1_archive and 
>>> table_name2_archive.  I'm pretty sure that by default if you haven't 
>>> explicitly provides some other name for the archive table web2py 
>>> automatically uses _archive which is exactly what I have 
>>> (because _enable_record_versioning() initially created the tables in the 
>>> database I restored from)
>>>
>>> On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:

 I think it because you use single archive table, could it be??

 If I remember there is many differents way to setup record versioning 
 feature...

 So what may happen in your case, if you have a single history table and 
 multiple ._enable_record_versing() for each table to be versioned, is that 
 web2py try to recreate the same history table each time he enconter the 
 _enable_record_versioning() 

 Personally I have evaluate the feature over auth_user table only for 
 now and make use of it as a per table history table... So, I init the 
 feature like so:

 db.auth_user._enable_record_versioning(archive_db=db,
archive_name='auth_user_archive',
current_record='current_record',
is_active='is_active')

 Where I specified the name of the table to use for archiving records...

 You may have a look at your history table(s) and try to set the 
 previous parameters for each of your instanciation of 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

Other possible explanation... Did you change app name? Sometimes this kind
of web2py feature use some part of web2py and app three in the name of
table created "automagically"...

For instance... I was having issue with session in database feature because
web2py use application name in the table name of the session in database
feature, so if I was not specify the name of the table in which I want the
session file to be store and I rename application (which I do in order to
test version tag and deploy) I wasn't able to execute tests because web2py
try to insert records in the wrong table... So I had to specify table name
like so :

session.connect(request, response, db, masterapp='APP_NAME')

So session goes in web2py_session_APP_NAME session for any clone of the
master app...

Richard


On Mon, Feb 22, 2016 at 11:09 PM, Richard Vézina <
ml.richard.vez...@gmail.com> wrote:

> Ok, so in this case, my theory is good... Try to leave just one
> _enable_record_versioning() for one turn... You try access your app with
> only one table under record versioning to see if it works... Then if this
> work, I would make sure (explicit) what is the name of the archive table to
> see if the issue go away...
>
> Richard
>
> On Mon, Feb 22, 2016 at 10:46 PM, Brian M  wrote:
>
>> No, not using single archive table. For each table I want archiving
>> enabled for, fortunately only a few, I have
>> db.table_name1._enable_archiving(), db.table_name2._enable_archiving() and
>> my database does that have separate tables for table_name1_archive and
>> table_name2_archive.  I'm pretty sure that by default if you haven't
>> explicitly provides some other name for the archive table web2py
>> automatically uses _archive which is exactly what I have
>> (because _enable_record_versioning() initially created the tables in the
>> database I restored from)
>>
>> On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:
>>>
>>> I think it because you use single archive table, could it be??
>>>
>>> If I remember there is many differents way to setup record versioning
>>> feature...
>>>
>>> So what may happen in your case, if you have a single history table and
>>> multiple ._enable_record_versing() for each table to be versioned, is that
>>> web2py try to recreate the same history table each time he enconter the
>>> _enable_record_versioning()
>>>
>>> Personally I have evaluate the feature over auth_user table only for now
>>> and make use of it as a per table history table... So, I init the feature
>>> like so:
>>>
>>> db.auth_user._enable_record_versioning(archive_db=db,
>>>archive_name='auth_user_archive',
>>>current_record='current_record',
>>>is_active='is_active')
>>>
>>> Where I specified the name of the table to use for archiving records...
>>>
>>> You may have a look at your history table(s) and try to set the previous
>>> parameters for each of your instanciation of the _enable_record_versioning()
>>>
>>> Richard
>>>
>>> On Mon, Feb 22, 2016 at 10:01 PM, Brian M  wrote:
>>>
 Um yeah I suppose I could let the DAL create the tables all itself and
 therefore also generate all of the expected .table files in the database
 folder and then go back in afterwards and do the actual DB restore on top
 of the new empty database. But it seems like I shouldn't really have to
 play tricks like that.

 The traceback error message is basically can't create
 table_name_archive an object with that name already exists. Sorry, don't
 have access to my work PC right now but that's the gist of it - can't
 create it is is already there.  It is the same error you'd get with any
 other table should you forget to turn off migrations/enable fake_migrate
 except there seems to be no way to do that for the automatically generated
 _archive tables you get with _enable_record_versioning().

 On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:
>
> What is the traceback error message?
>
> On Mon, Feb 22, 2016 at 9:53 PM, Brian M  wrote:
>
>> The restore was done with MS SQL Server's built-in backup & restore
>> so yes it has all of the tables and info. The dozens of other tables in 
>> my
>> database worked just fine with migrate=False, it seems  to be just the 
>> few
>> _archive ones that are having issues.
>>
>> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>>>
>>> If you restore database like for like, why are you bother with
>>> fake_migrate... Just leave everything to migrate=False should be 
>>> alright if
>>> you dump contains all the tables...
>>>
>>> Richard
>>>
>>> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>>>
 I seem to have run into a problem with tables 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

Ok, so in this case, my theory is good... Try to leave just one
_enable_record_versioning() for one turn... You try access your app with
only one table under record versioning to see if it works... Then if this
work, I would make sure (explicit) what is the name of the archive table to
see if the issue go away...

Richard

On Mon, Feb 22, 2016 at 10:46 PM, Brian M  wrote:

> No, not using single archive table. For each table I want archiving
> enabled for, fortunately only a few, I have
> db.table_name1._enable_archiving(), db.table_name2._enable_archiving() and
> my database does that have separate tables for table_name1_archive and
> table_name2_archive.  I'm pretty sure that by default if you haven't
> explicitly provides some other name for the archive table web2py
> automatically uses _archive which is exactly what I have
> (because _enable_record_versioning() initially created the tables in the
> database I restored from)
>
> On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:
>>
>> I think it because you use single archive table, could it be??
>>
>> If I remember there is many differents way to setup record versioning
>> feature...
>>
>> So what may happen in your case, if you have a single history table and
>> multiple ._enable_record_versing() for each table to be versioned, is that
>> web2py try to recreate the same history table each time he enconter the
>> _enable_record_versioning()
>>
>> Personally I have evaluate the feature over auth_user table only for now
>> and make use of it as a per table history table... So, I init the feature
>> like so:
>>
>> db.auth_user._enable_record_versioning(archive_db=db,
>>archive_name='auth_user_archive',
>>current_record='current_record',
>>is_active='is_active')
>>
>> Where I specified the name of the table to use for archiving records...
>>
>> You may have a look at your history table(s) and try to set the previous
>> parameters for each of your instanciation of the _enable_record_versioning()
>>
>> Richard
>>
>> On Mon, Feb 22, 2016 at 10:01 PM, Brian M  wrote:
>>
>>> Um yeah I suppose I could let the DAL create the tables all itself and
>>> therefore also generate all of the expected .table files in the database
>>> folder and then go back in afterwards and do the actual DB restore on top
>>> of the new empty database. But it seems like I shouldn't really have to
>>> play tricks like that.
>>>
>>> The traceback error message is basically can't create table_name_archive
>>> an object with that name already exists. Sorry, don't have access to my
>>> work PC right now but that's the gist of it - can't create it is is already
>>> there.  It is the same error you'd get with any other table should you
>>> forget to turn off migrations/enable fake_migrate except there seems to be
>>> no way to do that for the automatically generated _archive tables you get
>>> with _enable_record_versioning().
>>>
>>> On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:

 What is the traceback error message?

 On Mon, Feb 22, 2016 at 9:53 PM, Brian M  wrote:

> The restore was done with MS SQL Server's built-in backup & restore so
> yes it has all of the tables and info. The dozens of other tables in my
> database worked just fine with migrate=False, it seems  to be just the few
> _archive ones that are having issues.
>
> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>>
>> If you restore database like for like, why are you bother with
>> fake_migrate... Just leave everything to migrate=False should be alright 
>> if
>> you dump contains all the tables...
>>
>> Richard
>>
>> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>>
>>> I seem to have run into a problem with tables I'm using
>>> _enable_record_versioning() with. I'm setting up on a new computer and 
>>> have
>>> restored a DB backup to the new computer. Now when I try to run pages 
>>> that
>>> utilize those tables the database is complaining that the _archive 
>>> tables
>>> already exist.  I've tried
>>> db.table_name._enable_record_versioning(fake_migrate=True) but that
>>> argument isn't expected. I've tried using fake_migrate_all=True in the 
>>> DAL
>>> connection but that doesn't do it either. So what can I do to get 
>>> web2py to
>>> recognize that the archive table is already there and it doesn't need to
>>> try to recreate it.
>>>
>>> Brian
>>>
>>> --
>>> Resources:
>>> - http://web2py.com
>>> - http://web2py.com/book (Documentation)
>>> - http://github.com/web2py/web2py (Source code)
>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>> ---
>>> You received this 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

No, not using single archive table. For each table I want archiving enabled 
for, fortunately only a few, I have db.table_name1._enable_archiving(), 
db.table_name2._enable_archiving() and my database does that have separate 
tables for table_name1_archive and table_name2_archive.  I'm pretty sure 
that by default if you haven't explicitly provides some other name for the 
archive table web2py automatically uses _archive which is 
exactly what I have (because _enable_record_versioning() initially created 
the tables in the database I restored from)

On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:
>
> I think it because you use single archive table, could it be??
>
> If I remember there is many differents way to setup record versioning 
> feature...
>
> So what may happen in your case, if you have a single history table and 
> multiple ._enable_record_versing() for each table to be versioned, is that 
> web2py try to recreate the same history table each time he enconter the 
> _enable_record_versioning() 
>
> Personally I have evaluate the feature over auth_user table only for now 
> and make use of it as a per table history table... So, I init the feature 
> like so:
>
> db.auth_user._enable_record_versioning(archive_db=db,
>archive_name='auth_user_archive',
>current_record='current_record',
>is_active='is_active')
>
> Where I specified the name of the table to use for archiving records...
>
> You may have a look at your history table(s) and try to set the previous 
> parameters for each of your instanciation of the _enable_record_versioning()
>
> Richard
>
> On Mon, Feb 22, 2016 at 10:01 PM, Brian M  > wrote:
>
>> Um yeah I suppose I could let the DAL create the tables all itself and 
>> therefore also generate all of the expected .table files in the database 
>> folder and then go back in afterwards and do the actual DB restore on top 
>> of the new empty database. But it seems like I shouldn't really have to 
>> play tricks like that.
>>
>> The traceback error message is basically can't create table_name_archive 
>> an object with that name already exists. Sorry, don't have access to my 
>> work PC right now but that's the gist of it - can't create it is is already 
>> there.  It is the same error you'd get with any other table should you 
>> forget to turn off migrations/enable fake_migrate except there seems to be 
>> no way to do that for the automatically generated _archive tables you get 
>> with _enable_record_versioning().
>>
>> On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:
>>>
>>> What is the traceback error message?
>>>
>>> On Mon, Feb 22, 2016 at 9:53 PM, Brian M  wrote:
>>>
 The restore was done with MS SQL Server's built-in backup & restore so 
 yes it has all of the tables and info. The dozens of other tables in my 
 database worked just fine with migrate=False, it seems  to be just the few 
 _archive ones that are having issues.

 On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>
> If you restore database like for like, why are you bother with 
> fake_migrate... Just leave everything to migrate=False should be alright 
> if 
> you dump contains all the tables...
>
> Richard
>
> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>
>> I seem to have run into a problem with tables I'm using 
>> _enable_record_versioning() with. I'm setting up on a new computer and 
>> have 
>> restored a DB backup to the new computer. Now when I try to run pages 
>> that 
>> utilize those tables the database is complaining that the _archive 
>> tables 
>> already exist.  I've tried 
>> db.table_name._enable_record_versioning(fake_migrate=True) but that 
>> argument isn't expected. I've tried using fake_migrate_all=True in the 
>> DAL 
>> connection but that doesn't do it either. So what can I do to get web2py 
>> to 
>> recognize that the archive table is already there and it doesn't need to 
>> try to recreate it.
>>
>> Brian
>>
>> -- 
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> --- 
>> You received this message because you are subscribed to the Google 
>> Groups "web2py-users" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to web2py+un...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
 Resources:
 - http://web2py.com
 - http://web2py.com/book (Documentation)
 - http://github.com/web2py/web2py (Source code)
 - 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

I think it because you use single archive table, could it be??

If I remember there is many differents way to setup record versioning
feature...

So what may happen in your case, if you have a single history table and
multiple ._enable_record_versing() for each table to be versioned, is that
web2py try to recreate the same history table each time he enconter the
_enable_record_versioning()

Personally I have evaluate the feature over auth_user table only for now
and make use of it as a per table history table... So, I init the feature
like so:

db.auth_user._enable_record_versioning(archive_db=db,
   archive_name='auth_user_archive',
   current_record='current_record',
   is_active='is_active')

Where I specified the name of the table to use for archiving records...

You may have a look at your history table(s) and try to set the previous
parameters for each of your instanciation of the _enable_record_versioning()

Richard

On Mon, Feb 22, 2016 at 10:01 PM, Brian M  wrote:

> Um yeah I suppose I could let the DAL create the tables all itself and
> therefore also generate all of the expected .table files in the database
> folder and then go back in afterwards and do the actual DB restore on top
> of the new empty database. But it seems like I shouldn't really have to
> play tricks like that.
>
> The traceback error message is basically can't create table_name_archive
> an object with that name already exists. Sorry, don't have access to my
> work PC right now but that's the gist of it - can't create it is is already
> there.  It is the same error you'd get with any other table should you
> forget to turn off migrations/enable fake_migrate except there seems to be
> no way to do that for the automatically generated _archive tables you get
> with _enable_record_versioning().
>
> On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:
>>
>> What is the traceback error message?
>>
>> On Mon, Feb 22, 2016 at 9:53 PM, Brian M  wrote:
>>
>>> The restore was done with MS SQL Server's built-in backup & restore so
>>> yes it has all of the tables and info. The dozens of other tables in my
>>> database worked just fine with migrate=False, it seems  to be just the few
>>> _archive ones that are having issues.
>>>
>>> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:

 If you restore database like for like, why are you bother with
 fake_migrate... Just leave everything to migrate=False should be alright if
 you dump contains all the tables...

 Richard

 On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:

> I seem to have run into a problem with tables I'm using
> _enable_record_versioning() with. I'm setting up on a new computer and 
> have
> restored a DB backup to the new computer. Now when I try to run pages that
> utilize those tables the database is complaining that the _archive tables
> already exist.  I've tried
> db.table_name._enable_record_versioning(fake_migrate=True) but that
> argument isn't expected. I've tried using fake_migrate_all=True in the DAL
> connection but that doesn't do it either. So what can I do to get web2py 
> to
> recognize that the archive table is already there and it doesn't need to
> try to recreate it.
>
> Brian
>
> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to the Google
> Groups "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to web2py+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 --
>>> Resources:
>>> - http://web2py.com
>>> - http://web2py.com/book (Documentation)
>>> - http://github.com/web2py/web2py (Source code)
>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "web2py-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to web2py+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to the Google Groups
> "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to web2py+unsubscr...@googlegroups.com.
> For more options, visit 

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

Um yeah I suppose I could let the DAL create the tables all itself and 
therefore also generate all of the expected .table files in the database 
folder and then go back in afterwards and do the actual DB restore on top 
of the new empty database. But it seems like I shouldn't really have to 
play tricks like that.

The traceback error message is basically can't create table_name_archive an 
object with that name already exists. Sorry, don't have access to my work 
PC right now but that's the gist of it - can't create it is is already 
there.  It is the same error you'd get with any other table should you 
forget to turn off migrations/enable fake_migrate except there seems to be 
no way to do that for the automatically generated _archive tables you get 
with _enable_record_versioning().

On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:
>
> What is the traceback error message?
>
> On Mon, Feb 22, 2016 at 9:53 PM, Brian M  
> wrote:
>
>> The restore was done with MS SQL Server's built-in backup & restore so 
>> yes it has all of the tables and info. The dozens of other tables in my 
>> database worked just fine with migrate=False, it seems  to be just the few 
>> _archive ones that are having issues.
>>
>> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>>>
>>> If you restore database like for like, why are you bother with 
>>> fake_migrate... Just leave everything to migrate=False should be alright if 
>>> you dump contains all the tables...
>>>
>>> Richard
>>>
>>> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>>>
 I seem to have run into a problem with tables I'm using 
 _enable_record_versioning() with. I'm setting up on a new computer and 
 have 
 restored a DB backup to the new computer. Now when I try to run pages that 
 utilize those tables the database is complaining that the _archive tables 
 already exist.  I've tried 
 db.table_name._enable_record_versioning(fake_migrate=True) but that 
 argument isn't expected. I've tried using fake_migrate_all=True in the DAL 
 connection but that doesn't do it either. So what can I do to get web2py 
 to 
 recognize that the archive table is already there and it doesn't need to 
 try to recreate it.

 Brian

 -- 
 Resources:
 - http://web2py.com
 - http://web2py.com/book (Documentation)
 - http://github.com/web2py/web2py (Source code)
 - https://code.google.com/p/web2py/issues/list (Report Issues)
 --- 
 You received this message because you are subscribed to the Google 
 Groups "web2py-users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to web2py+un...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "web2py-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to web2py+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

What is the traceback error message?

On Mon, Feb 22, 2016 at 9:53 PM, Brian M  wrote:

> The restore was done with MS SQL Server's built-in backup & restore so yes
> it has all of the tables and info. The dozens of other tables in my
> database worked just fine with migrate=False, it seems  to be just the few
> _archive ones that are having issues.
>
> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>>
>> If you restore database like for like, why are you bother with
>> fake_migrate... Just leave everything to migrate=False should be alright if
>> you dump contains all the tables...
>>
>> Richard
>>
>> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>>
>>> I seem to have run into a problem with tables I'm using
>>> _enable_record_versioning() with. I'm setting up on a new computer and have
>>> restored a DB backup to the new computer. Now when I try to run pages that
>>> utilize those tables the database is complaining that the _archive tables
>>> already exist.  I've tried
>>> db.table_name._enable_record_versioning(fake_migrate=True) but that
>>> argument isn't expected. I've tried using fake_migrate_all=True in the DAL
>>> connection but that doesn't do it either. So what can I do to get web2py to
>>> recognize that the archive table is already there and it doesn't need to
>>> try to recreate it.
>>>
>>> Brian
>>>
>>> --
>>> Resources:
>>> - http://web2py.com
>>> - http://web2py.com/book (Documentation)
>>> - http://github.com/web2py/web2py (Source code)
>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "web2py-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to web2py+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to the Google Groups
> "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

The restore was done with MS SQL Server's built-in backup & restore so yes 
it has all of the tables and info. The dozens of other tables in my 
database worked just fine with migrate=False, it seems  to be just the few 
_archive ones that are having issues.

On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>
> If you restore database like for like, why are you bother with 
> fake_migrate... Just leave everything to migrate=False should be alright if 
> you dump contains all the tables...
>
> Richard
>
> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  
> wrote:
>
>> I seem to have run into a problem with tables I'm using 
>> _enable_record_versioning() with. I'm setting up on a new computer and have 
>> restored a DB backup to the new computer. Now when I try to run pages that 
>> utilize those tables the database is complaining that the _archive tables 
>> already exist.  I've tried 
>> db.table_name._enable_record_versioning(fake_migrate=True) but that 
>> argument isn't expected. I've tried using fake_migrate_all=True in the DAL 
>> connection but that doesn't do it either. So what can I do to get web2py to 
>> recognize that the archive table is already there and it doesn't need to 
>> try to recreate it.
>>
>> Brian
>>
>> -- 
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "web2py-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to web2py+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

Not very orthodox method here, but let say you have dump just the data and
want to let web2py recreate everything...

Make a backup of the app before do anything else so you can restart over if
it not working properly with previous state.

Then go in the app/database/ folder and delete everything there... Then
update you db.py connection string to point over the new database server
with an empty fresh database and set migrate=True... Run web2py and access
your app... Web2py will recreate the whole database...

Then you insert your data.

Richard

On Mon, Feb 22, 2016 at 9:39 PM, Richard Vézina  wrote:

> If you restore database like for like, why are you bother with
> fake_migrate... Just leave everything to migrate=False should be alright if
> you dump contains all the tables...
>
> Richard
>
> On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:
>
>> I seem to have run into a problem with tables I'm using
>> _enable_record_versioning() with. I'm setting up on a new computer and have
>> restored a DB backup to the new computer. Now when I try to run pages that
>> utilize those tables the database is complaining that the _archive tables
>> already exist.  I've tried
>> db.table_name._enable_record_versioning(fake_migrate=True) but that
>> argument isn't expected. I've tried using fake_migrate_all=True in the DAL
>> connection but that doesn't do it either. So what can I do to get web2py to
>> recognize that the archive table is already there and it doesn't need to
>> try to recreate it.
>>
>> Brian
>>
>> --
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "web2py-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to web2py+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Richard Vézina]

If you restore database like for like, why are you bother with
fake_migrate... Just leave everything to migrate=False should be alright if
you dump contains all the tables...

Richard

On Mon, Feb 22, 2016 at 4:55 PM, Brian M  wrote:

> I seem to have run into a problem with tables I'm using
> _enable_record_versioning() with. I'm setting up on a new computer and have
> restored a DB backup to the new computer. Now when I try to run pages that
> utilize those tables the database is complaining that the _archive tables
> already exist.  I've tried
> db.table_name._enable_record_versioning(fake_migrate=True) but that
> argument isn't expected. I've tried using fake_migrate_all=True in the DAL
> connection but that doesn't do it either. So what can I do to get web2py to
> recognize that the archive table is already there and it doesn't need to
> try to recreate it.
>
> Brian
>
> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to the Google Groups
> "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[web2py] Restored DB, _enable_record_versioning() and fake migrations?

[Brian M]

I seem to have run into a problem with tables I'm using 
_enable_record_versioning() with. I'm setting up on a new computer and have 
restored a DB backup to the new computer. Now when I try to run pages that 
utilize those tables the database is complaining that the _archive tables 
already exist.  I've tried 
db.table_name._enable_record_versioning(fake_migrate=True) but that 
argument isn't expected. I've tried using fake_migrate_all=True in the DAL 
connection but that doesn't do it either. So what can I do to get web2py to 
recognize that the archive table is already there and it doesn't need to 
try to recreate it.

Brian

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.