On 16 April 2012 16:03, Massimo Di Pierro wrote:
> No. Batch operations do not bypass the auditing process.
>
Thanks.
Regards
Johann
--
Because experiencing your loyal love is better than life itself,
my lips will praise you. (Psalm 63:3)
No. Batch operations do not bypass the auditing process.
On Monday, 16 April 2012 08:52:22 UTC-5, Johann Spies wrote:
>
> On 16 April 2012 15:18, Massimo Di Pierro wrote:
>
>> Yes but if you do a batch delete or update web2py has to copy all records
>> from one table to another one by one. That m
On 16 April 2012 15:18, Massimo Di Pierro wrote:
> Yes but if you do a batch delete or update web2py has to copy all records
> from one table to another one by one. That may cause a significati slowdown
> that will lock the db for long time. It may have bad consequences.
>
Thanks for your answer
Yes but if you do a batch delete or update web2py has to copy all records
from one table to another one by one. That may cause a significati slowdown
that will lock the db for long time. It may have bad consequences.
On Monday, 16 April 2012 04:56:54 UTC-5, Johann Spies wrote:
>
> Will this audi
Will this auditing also work with changes in data that does not come from
form-submission? Say for instance I run a batch update/delete from a
script or using 'selectable' in a grid to select a number of records to be
deleted, will that not bypass the auditing?
I ask because calculated fields are
Fixed in trunk.
On Saturday, 14 April 2012 23:10:18 UTC-5, tomt wrote:
>
> I discovered why the archive table wasn't being created, there is a typo
> in gluon/tools.py at line 1293:
> for table in tables:
> if 'modifed_on' in table.fields():
> should be
> for table in
I discovered why the archive table wasn't being created, there is a typo in
gluon/tools.py at line 1293:
for table in tables:
if 'modifed_on' in table.fields():
should be
for table in tables:
if 'modified_on' in table.fields():
Now the the 'mythings_archi
I'm have been trying to test this new audit function in trunk, but so far
the mything_archive table has never been created in any of my tests.
Is this the current state of the implementation, or am I missing something?
I downloaded the latest trunk and used it web2py admin to create a new app.
Thanks Massimo. Will do.
I'll test it against Oracle today as well.
On Wednesday, 11 April 2012 06:40:56 UTC+2, Massimo Di Pierro wrote:
>
> This helps a lot. WIll check this asap. To make sure I do not foget and it
> tracked, plase open an issue in google code.
>
>
> On Tuesday, 10 April 2012
This helps a lot. WIll check this asap. To make sure I do not foget and it
tracked, plase open an issue in google code.
On Tuesday, 10 April 2012 14:12:38 UTC-5, Rakesh Singh wrote:
>
> Hi Massimo,
>
> Regarding the MySQL error, re-created the database and started a new app
> with auth.signatu
Hi Massimo,
Regarding the MySQL error, re-created the database and started a new app
with auth.signature=True
Here is the auth_user creation log on MySQL followed by the insert that
generates the error :
CREATE TABLE auth_user(
id INT AUTO_INCREMENT NOT NULL,
first_name VARCHAR(128),
I agree that is people would normally use the feature. And that's a matter
of deleting older archived records. What I am not sure is if it should be
built-in into web2py.
If would be easy to do db(db.table_archive).delete() which event should
trigger it? perhaps this is one of those actions sho
Hi,
It looks like a great new feature... I would suggest something. Instead of
copying every update, I would keep the records only once the it gets in a
particular state. In my case a records could have no review, can be
reviewed and approved, so I just want to keep the changes that occured once
t
Actually I was wrong. this is not the problem. Web2py does the right thing.
Is there any way you can look into the mysql logs what is the sql string
that causes the problem?
On Tuesday, 10 April 2012 08:23:03 UTC-5, Massimo Di Pierro wrote:
>
> I figured this out. The table has a self reference
I figured this out. The table has a self reference and web2py inserts a
zero in it instead of NULL. Works for sqlite but not MySQL.
Changing zero with NULL may be treated as a bug fix it will constitute a
minor change of backward compatibility in case you incorrectly do
db(db.table.reference_fi
I have declared the table in db.py with auth.signature, and uncommented
auth.enable_record_versioning(db), but the _archive table isn't created.
- Tom
On Monday, April 9, 2012 8:33:18 AM UTC-6, Massimo Di Pierro wrote:
>
> the signature=True only adds a signature to the auth_* tables so that if
the signature=True only adds a signature to the auth_* tables so that if a
user creates an account for another user or creates a group, you can keep
track of who did it.
The mything_archive table should be created by:
auth.enable_record_versioning(db)
This should be called after the mything ta
Hi,
Thanks for your response. I deleted the database as you suggested and
changed signature=False. The problem did go away and I was able to add
users without the error.
I then reverted to signature=True. While subsequent modifications did show
the signature, the 'mything_archive' was never
Hi,
I have received the same error as Tom on MySQL (5.5.22) when adding a user
to the auth_user table via the Database Administration screen.
(1452, u'Cannot add or update a child row: a foreign key constraint fails)
Reverting back to "signature=False" resulted in an error (Trace below) :
Inte
Can you try again with mysql, delete the database and replace:
auth.define_tables(signature=True)
with
auth.define_tables(signature=False)
Does the problem does away? It looks like it does not like the self
reference in auth_user.
On Saturday, 7 April 2012 22:09:31 UTC-5, tomt wrote:
>
> Hi,
>
Hi,
I tried using your new versioning feature in trunk.
I created an app using a mysql database:
db = DAL('mysql://version:version@localhost/version')
When I used the admin function to define a new user
I received the following error:
(1452, u'Cannot add
21 matches
Mail list logo
