Thanks for the quick response.
1. To clarify, you CANNOT use the CRUD archive methods on the back.
You must do the work yourself, like the example above, right?
2. I haven't seen the ** notation before. Is it literal, or do you
mean that I will have to list all the fields within the parentheses?
Thanks again!
On Mar 21, 11:09 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> given
>
> db.define_table('mytable',....)
> db.define_table('mytable_history',
>
> Field('current_record',db.mytable),
> db.mytable)
>
> before
>
> db(db.mytable.id==id).update(**fields)
>
> you need to retrieve and archive the current record
>
> current = db.mytable[id]
> current.current_record = current.id # move id
>
> db.mytable_history.insert(**mytable_history._filter_fields(current))
>
> On Mar 21, 9:44 am, Matthew <matthew.g.nor...@gmail.com> wrote:
>
> > Is there a way to do this (and to use CRUD, in general) in a scheduled
> > job rather than just the web frontend?
>
> > On Feb 13, 1:18 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > Here is a new feature in trunk.
>
> > > Say you have the following table:
>
> > > db.define_table('person',
> > > Field('name'),
>
> > > Field('created_by',default=auth.user_id,update=auth.user_id,writable=False),
>
> > > Field('created_on',default=request.now,update=request.now,writable=False))
>
> > > and you want to store all previous version of this record as it gets
> > > edited. Now you can do:
>
> > > 1) create a table where to store them:
>
> > > db.define_table('person_archive',Field('current_record',db.person),db.person)
>
> > > (the name has to be <table>_archive and it must contain a
> > > 'current_record' field pointing to the actual table, it must also
> > > contain by all fields of the actual table).
>
> > > 2) use onaccept=crud.archive in crud.update
>
> > > def index():
> > > form = crud.update(db.person, request.args(0),
> > > onaccept=crud.archive)
> > > return dict(form=form)
>
> > > Details:
> > > - actually you do not need step 1, the archive table is created
> > > automatically in step 2. you need step 1 only if/when you want to
> > > access the archive table for other purpose such as retrieving the
> > > data.
> > > - you can change 'person_archive' and 'current_record' by passing
> > > parameters to crud.archive.
> > > - there is nothing special about the fields 'created_by' and
> > > 'created_on', you should have them but can call them as you like.
>
> > > Pros:
>
> > > - Just adding "onaccept=crud.archive" to crud.update of your current
> > > app makes sure all changes are archived and you have full auditing for
> > > you app.
> > > - references never break (because current_record never changes id).
> > > - It does not slow down the app because current data and archived data
> > > are on different tables
> > > - no unnecessary code since the archive table is defined only when
> > > needed
> > > - works on GAE
>
> > > Cons:
> > > - if you delete a record, the last one gets archived but it does not
> > > record who deleted the record. To achieve this you would need an extra
> > > field, for example "active", and set this to false, instead of
> > > deleting the record. Then modify logic of the app to use this "active"
> > > field. Not really a cons actually. This is the only way to do it that
> > > allows users to un-delete records or restore previous revisions
> > > without breaking links.
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
