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.
