For the "stamp" columns do you not think that the default should be like the 'id' column - do not expose/display?
On Oct 18, 12:11 am, mdipierro <[EMAIL PROTECTED]> wrote: > for your own tables you should do > > db.tablename.esposes=['field1','field2','etc'] > > to list the fields that you want to appear in forms and exclude those > you do not want. > > db.tablename.displays=['field1','field2','etc'] > > to list fields that should be displayed by t2.display > > I will look into the other issues. > > On Oct 17, 5:58 pm, billf <[EMAIL PROTECTED]> wrote: > > > I am trying to test the behaviour of the new t2 "stamped" columns. > > > The T2 manual says of the "Stamp" pattern: "Automatically stamp table > > records for creation date, author, last modification date and author > > of the last modification." I thought initially that this meant that > > those columns would be automatically added to all tables (like id) but > > now I can see from the _stamp() method how the 8 columns are stamped > > if present however I have a few observations: > > > In my example table I have included created_on and modified_on simple > >c; as 'datetime' and no other attributes. > > > 1) The auto create view exposes both created_on and modified_on as > > input fields and insists on datetimes being entered. I would have > > expected that neither column should be exposed as any input will be > > overridden by _stamp(). > > > 2) The automatic update view exposes both created_on and modified_on > > as input fields and insists on datetimes being entered. I would have > > expected that both columns should be display only and any input > > ignored or responded to as "error tampered with". It must be illegal > > to change the create attributes and the modified attributes should be > > set by _stamp(). > > > 3) When a record is updated the modified_on timestamp does not > > change. I think this is because _stamp() stores the new stamp values > > in form.vars but these values never make it into the fields[] list > > that is used to update the record on the database. > > > 4) (referring back to an earlier thread) the modified_on value is not > > included in the update and delete condition to highlight race > > conditions. To a degree, I can understand this as t2 is built upon > > web2py and the update() and delete() methods are in web2py. Perhaps a > > solution would be the ability to pass SQLFORM an argument to be used > > as the condition in update() and delete(). This would default to > > "self.table.id==self.record.id" but could be passed in from t2 as > > "self.table.id== self.record.id and > > self.table.modified_on==self.record.modified_on" if the modified_on > > column was present. This would seem to keep the backwards > > compatibility of web2py but allow t2 to utilise the new modified_on > > column. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
