[web2py] Re: Record Versioning ON, result 'id'

Have you changed the structure of the table being archived? I have had instances in the past where I have added an extra field to my table and all works OK until I change a record. At that point, archiving fails because there is now a mismatch between the structure of the table and the

[web2py] Re: Record Versioning not working for just one table (?)

thanks Once I added *db.actions._enable_record_versioning*() [in addition to the global auth.enable_record_versioning(db), ] this seemed to fix it. On Tuesday, September 6, 2016 at 6:06:00 PM UTC+1, Anthony wrote: > By default, record versioning creates a "current_record" reference field > in

[web2py] Re: Record Versioning not working for just one table (?)

By default, record versioning creates a "current_record" reference field in the archive table to point to the original record (i.e., the current version of the record in the original table), but your table already has its own "current_record" boolean field (which prevents record versioning

[web2py] Re: record versioning

web2py does not support the SQL UNION statement, but you can separately query the two tables and generate the union of the two Rows objects via Python: all_records = db(db.mytable).select() | db(db.mytable_archive).select() See

Re: [web2py] Re: record versioning

thanks! 2015-12-01 17:21 GMT-02:00 Anthony : > web2py does not support the SQL UNION statement, but you can separately > query the two tables and generate the union of the two Rows objects via > Python: > > all_records = db(db.mytable).select() |

[web2py] Re: record versioning

Not sure I understand, why union (join?)? is this because the last record is not the archive table? On Monday, 30 November 2015 11:31:46 UTC-6, Fabiano Almeida wrote: > > Hi All! > > I need create a report with record versioning. How to union table with > table_archive? > > Thanks! > --

[web2py] Re: record versioning on auth tables

make sense, thank you so much for detail explaination, massimo. thanks and best regards, stifan -- 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

[web2py] Re: record versioning on auth tables

Because they do not have a signature (modified_by, modified_on). They do not have a signature because they are meant to be write only and they are meat to be written even before a user logs in. On Friday, 26 June 2015 15:52:56 UTC-5, 黄祥 wrote: hi, just wondering about record versioning on

[web2py] Re: Record versioning without duplicate archive records?

Please open a ticket about this. It makes sense. On Tuesday, 12 August 2014 13:41:13 UTC-5, Jack Kuan wrote: Hi, just starting out with web2py. Given a table with record versioning enabled, I find that for every successful update operation a row will be inserted in the archive table. I'm

[web2py] Re: record versioning and standalone DAL

To record versiong works, you should set db._common_fields.append(auth.signature) after you db.define_tables() but before defining any other table and db.enable_record_versioning(db) after you define all tables Em segunda-feira, 30 de setembro de 2013 17h28min12s UTC-3, JaapP escreveu:

[web2py] Re: Record versioning on delete CASCADE

Good point. But in my point of view you wont use record versioning at all your tables, just in the ones that have sensitive data. And yet, you dont use ondelete cascade in all tables too... I still think record versioning should have this standard behaviour. On Sunday, February 3, 2013 1:14:21

[web2py] Re: Record versioning on delete CASCADE

No, I mean, when a record is delete aka is_active is seted to False, the other records there make reference to it are seted false too? On Friday, February 1, 2013 6:19:52 PM UTC-2, Massimo Di Pierro wrote: When using versioning. Latest versions of records are never deleted, only filtered

[web2py] Re: Record versioning on delete CASCADE

Good point. No. they are not set to is_active=False. Should they? On Saturday, 2 February 2013 06:20:47 UTC-6, Felipe Meirelles wrote: No, I mean, when a record is delete aka is_active is seted to False, the other records there make reference to it are seted false too? On Friday, February

[web2py] Re: Record versioning on delete CASCADE

I think they should, to be compatible with the default behaviour. Is this possible to do? On Saturday, February 2, 2013 6:41:25 PM UTC-2, Massimo Di Pierro wrote: Good point. No. they are not set to is_active=False. Should they? On Saturday, 2 February 2013 06:20:47 UTC-6, Felipe Meirelles

[web2py] Re: Record versioning on delete CASCADE

It is possible but very very inefficient since it would not be handled at the database level. On Saturday, 2 February 2013 15:44:20 UTC-6, Felipe Meirelles wrote: I think they should, to be compatible with the default behaviour. Is this possible to do? On Saturday, February 2, 2013 6:41:25

[web2py] Re: Record versioning on delete CASCADE

I should explain my answer. In order to have record versioning, record must be copied. To have a cascade delete we would have to loop and copy each individual record. Those records themselves could have references. More looping. etc. This are even more complex since there may be non-trivial

[web2py] Re: Record versioning on delete CASCADE

When using versioning. Latest versions of records are never deleted, only filtered out. I think cascade should work as expected. On Friday, 1 February 2013 11:54:25 UTC-6, Felipe Meirelles wrote: The cascade feature should work for record versioning enabled tables? Thanks. -- --- You

[web2py] Re: record versioning: what if tables are manually changed with migrate=False?

You can do: DAL(, migrate_enabled=False) and no table will be migrated ever. On Wednesday, 16 January 2013 23:41:42 UTC-6, Rick Ree wrote: Thanks Massimo. For this app we use migrate=False for all tables because of issues that arose in the context of distributed development using git.

[web2py] Re: record versioning: what if tables are manually changed with migrate=False?

If you do db=DAL(, migrate_enabled=True) # default behavior auth.enable_record_versioning(db) db.define_table('something',, migrate=False) ... The migrate=False only affect the something table. If you change its model that table will not migrate but associated archive table will. If

[web2py] Re: record versioning: what if tables are manually changed with migrate=False?

Thanks Massimo. For this app we use migrate=False for all tables because of issues that arose in the context of distributed development using git. Basically, developers are using different MySQL servers, not all on localhost. So the *.table files were different, and so we did not put them in

Re: [web2py] Re: Record Versioning

No, I'm simply playing with SQLite. It's only for evaluation only. Anyway, I also noticed that it would store a new record regardless there is a modification in a field or not. Is it normal? Is there a way to avoid storing new record if in the end there is no difference when compared to

Re: [web2py] Re: Record Versioning

If you are using mysql db, you can try to use triggers instead of all of this.

[web2py] Re: Record Versioning

JF, did you try to remove default=request.now from created_on? On Dec 27, 4:55 pm, JF jf_sic...@hotmail.com wrote: Have another issue.  It seems the datetime in my archive will always be the datetime of creation of the initial record, not the updates. Here is a glimpse of the Model:

[web2py] Re: Record Versioning

This should work. Which version? If you have the bug with the latest version please open a ticket in google code. On Dec 27, 2:55 am, JF jf_sic...@hotmail.com wrote: Have another issue.  It seems the datetime in my archive will always be the datetime of creation of the initial record, not the

[web2py] Re: Record Versioning

Have another issue. It seems the datetime in my archive will always be the datetime of creation of the initial record, not the updates. Here is a glimpse of the Model: -- db.define_table('part',

[web2py] Re: Record Versioning

Hi, I was working on 1.99.4, Cleaned the Application, Packed it to give it a try with 1.99.3. It actually worked correctly with 1.99.3. But it turns out that it is the Clean up that fixed the problem. Probably that the few modifications I made to the tables corrupted the database.

[web2py] Re: Record Versioning

I don't know if having a field using the same name as the table was a problem, but I changed it anyway. It was confusing. But I finally figured out my problem was in the following lines (Note that I replaced the table name from mpn to part: db.part.iditm.requires = IS_IN_DB(db, 'item.ipn')

[web2py] Re: Record Versioning findings

On Oct 29, 4:09 pm, baloan balo...@googlemail.com wrote: 3. In the documentation the archive table is defined like db.define_table('mytable_history',    Field('current_record',db.mytable),    db.mytable) while in the current version it is defined like db.define_table('mytable_arcvhive',  

[web2py] Re: Record Versioning findings

fixed in 1.88.2 On Oct 29, 4:45 pm, cjrh caleb.hatti...@gmail.com wrote: On Oct 29, 4:09 pm, baloan balo...@googlemail.com wrote: 3. In the documentation the archive table is defined like db.define_table('mytable_history',    Field('current_record',db.mytable),    db.mytable) while

[web2py] Re: Record Versioning

The problem is that update=auth.user.username the right hand site is node defined if you are not logged in. Try: update=auth.user and auth.user.username On Oct 27, 4:50 pm, baloan balo...@googlemail.com wrote: I am trying to use versioning in an authenticated section of a website. Instead of