I have a possible solution in trunk. If you say default=None it does what you say and oncreate ignores update. If you do not specify a default but you do specify an update, default==update.
Would this be acceptable? Massimo On Nov 8, 4:25 pm, mdipierro <[email protected]> wrote: > On Nov 8, 4:11 pm, Vinicius Assef <[email protected]> wrote: > > > On Mon, Nov 8, 2010 at 5:49 PM, mdipierro <[email protected]> wrote: > > > Hi Vinicius, > > > > I think there are two issues. > > > > The fact that models are executed at every http request and therefore > > > values are set there is explained in the manual. > > > I couldn't find that in DAL chapter > > (http://web2py.com/book/default/chapter/06). > > Where is it? > > GRRRRRR. you are right! This is the most important issue and it is so > important that I assumed I spelled it clearly but looks like I did > not. > This calls for a major revision of chapter 3. Thanks for pointing this > out. > > About your comments below. Let's hear form more people and I will also > sleep on it. > > Massimo > > > > I can understand the confusion when coming form other frameworks but > > > there is nothing new there. > > > Actually, I didn't bring my expectation from other frameworks. I > > brought it from my database experience. > > Even defining the default clausule in CREATE TABLE, it is evaluated > > every time a new row is stored. > > > About the update param, again I thought in terms of database events, > > not about http request event. > > > As web2py intends to serve mainly database driven apps, I thought it > > would have the same behaviour. In spite of where the request is coming > > from: http, cron or shell. > > > It would be *very* nice if we have this kind of behaviour centralized > > in models, independent of forms. > > New records with new dynamic default/update values, ie, datetime.now(). > > > > The current design is motivated by the fact that it is not a good idea > > > to leave those values NULL (None) because they are supposed to be > > > dates. If you have None in there, you end up needing a lots of check > > > in the code when you try to format the dates to take care of None > > > dates. > > > OK. I agree with you if notnull=True. But if I allow some Field to > > have null value, where is the problem? > > If the database allows me, why web2py shouldn't? > > > > update='...' is used for timestamps therefore its value should not be > > > displayed in the form. If it were to be displayed it would be wrong > > > anyway, because the stored value would be recomputed with the second > > > http request that performs the insert. > > > I agree with you. > > > But if the field is datetime, I would write 'default=None, > > update=datetime.now()'. It leads developer to think: "this field will > > be empty when inserted, and populated only when updated". > > > To work as you implemented, it would be explicit: > > 'default=datetime.now(), update=datetime.now()'. It leads developer to > > think: "this field will have datetime.now() when inserted and will be > > updated with the new datetime.now() when updated." > > > Explicit is better than implicit, right? > > > I made one workaround to achieve my needs: "default='1900-01-01 > > 00:00:00', update=datetime.now()'. > > This worked here and is an applicable solution to my case. > > > Again, I think this behaviour (default=update in absense of the first) > > must be explicit in the manual. Please. > > > > The current design still allows you to check whether a field was or > > > not updated by comparing the created_on with the updated_on date. > > > Right. :-) > > > But an index search by "where updated_on > '1900-01-01 00:00:00'" is > > much faster than "where updated_on = created_on", right? > > > > Because this is not clear in the docs we either have to revise the > > > docs or change its behavior (the latter would break some users'code) > > > and I think fixing the docs is a better approach. > > > Massimo, IMO one of the great web2py characteristics is keeping > > backwards compatibility. > > Actually, this what most motivated me to learn and use web2py. Knowing > > that what I make will work forever is too comfortable. :-) > > > There are ways of doing all of that, creating new params at table or > > field level to reflect new behaviour, if necessary, and also keeping > > backwards compatibility. > > > About inserting refreshed default and update values: > > refresh_value_on_each_call=False/True. > > About not assuming default=update: > > default_equals_to_update_if_absent=False/True. > > > To end my participation here, I loved web2py and my comments is to > > help building a more intuitive and robust solution. It's *not* to > > criticize your great work. > > > As I have large experience with corporate development, I'm used to see > > some smells of possible mess, sometimes. > > > I'm here to help, not to perturb you all. > > > -- > > Vinicius Assef. > > > > Anyway, I'd like to hear more opinions about this. > > > > Massimo > > > > On Nov 8, 1:35 pm, Vinicius Assef <[email protected]> wrote: > > >> OK. Understood. > > > >> But I must say it doesn't conform with web2py documentation. > > > >> About default, the book says: default sets the default value for the > > >> field. The default value is used when performing an insert if a value > > >> is not explicitly specified. It is also used to pre-populate forms > > >> built from the table using SQLFORM. > > > >> Assuming default==update may be a source of confusion and unexpected > > >> behaviour. I tried it today. I lost almost a day trying to figure it > > >> out. > > >> In spite of that, how can I have my example field filled with None > > >> when inserted and just populated when updated? > > >> Note that I'm running from shell because I intent to run this process > > >> by a cron job. So, http requests are not present here. > > > >> About update, the book says: update contains the default value for > > >> this field when the record is updated. > > > >> Well, again, assuming default==update is not what manual says. > > >> When developing database applications, update is understood as an > > >> event that occurs when something changes in your *existing* record (or > > >> row, if purists read this.). So, assume default content is equal > > >> update content may not be a good practice here, and, again, source of > > >> confusion. > > > >> Another comment, if allowed, is about datetime.now() be evaluated just > > >> when the table is defined. It is not explicit in book, too. > > >> If I have a background process listening to some semaphores and > > >> updating and inserting records through a cron job, it's worthless and, > > >> again, my be a source of misunderstanding. > > > >> Massimo, I ask you to think about that and inform us if web2py way of > > >> doing theses things will change or documentation will be updated to > > >> reflect this behaviour. > > > >> -- > > >> Vinicius Assef. > > > >> On Mon, Nov 8, 2010 at 5:09 PM, mdipierro <[email protected]> > > >> wrote: > > >> > no. if you have update but not default, default==update. > > > >> > On Nov 8, 1:02 pm, Vinicius Assef <[email protected]> wrote: > > >> >> Thanks, Massimo. > > > >> >> But, when the record is inserted, the field with "update" param > > >> >> shouldn't be None? > > > >> >> -- > > >> >> Vinicius Assef. > > > >> >> On Mon, Nov 8, 2010 at 4:58 PM, mdipierro <[email protected]> > > >> >> wrote: > > >> >> > This is misunderstanding. Yes what you have is correct. > > > >> >> > The default=datetime.now() and update=datetime.now() is evaluated > > >> >> > only > > >> >> > ONCE when the table is defined therefore when you insert and update > > >> >> > the values are always the same. > > > >> >> > BUT > > > >> >> > when the code is in a web2py controller, the model is run again at > > >> >> > every http request and therefore the values of default and request > > >> >> > will be updated. > > > >> >> > Massimo > > > >> >> > On Nov 8, 12:51 pm, Vinicius Assef <[email protected]> wrote: > > >> >> >> Buddies, this is what is happening, step by step: > > > >> >> >>http://pastebin.com/b14HLy39 > > > >> >> >> This test was made with latest stable version: Version 1.88.2 > > >> >> >> (2010-10-29 23:04:43) > > > >> >> >> Again, am I missing something? > > > >> >> >> I don't think there is a bug here. I expect I am making a really > > >> >> >> big > > >> >> >> and stupid mistake. > > >> >> >> This is too important to not be working out. > > > >> >> >> By the way: I'm using Ubuntu 9.04. > > > >> >> >> -- > > >> >> >> Vinicius Assef. > > > >> >> >> On Mon, Nov 8, 2010 at 3:13 PM, Vinicius Assef > > >> >> >> <[email protected]> wrote: > > >> >> >> > Massimo, I expect the correct way is: > > > >> >> >> > a) When inserting (sql insert) a new record: > > >> >> >> > 1) was_inserted_on receives request.now contents (this is ok) > > >> >> >> > 2) was_updated_on receives null > > > >> >> >> > b) When updating (sql update) a record: > > >> >> >> > 1) was_inserted_on doesn't change is value (this is ok) > > >> >> >> > 2) was_update_on receives request.now > > > >> >> >> > What is happening here, with web2py 1.87.3 and SQLite: > > > >> >> >> > a) When inserting (sql insert) a new record: > > >> >> >> > 1) was_inserted_on receives request.now content > > >> >> >> > 2) was_updated_on receives request.now content > > > >> >> >> > b) When updating (sql update) a record: > > >> >> >> > 1) was_inserted_on doesn't change its value > > >> >> >> > 2) was_update_on doesn't change its value > > > >> >> >> > Am I loosing something? > > > >> >> >> > -- > > >> >> >> > Vinicius Assef. > > > >> >> >> > On Mon, Nov 8, 2010 at 2:27 PM, mdipierro > > >> >> >> > <[email protected]> wrote: > > >> >> >> >> What you expect is correct and I cannot reproduce the problem. > > >> >> >> >> how do > > >> >> >> >> you update the record? > > > >> >> >> >> On Nov 8, 8:54 am, Vinicius Assef <[email protected]> wrote: > > >> >> >> >>> I have this model just for test:http://pastebin.com/vF4VBLLM > > > >> >> >> >>> Field 'was_inserted_on' is working all right. It has default > > >> >> >> >>> insert > > >> >> >> >>> value and it isn't updated across record updates. It's ok. > > > >> >> >> >>> But 'was_updated_on' is working the same way. > > > >> >> >> >>> I imagined it was null when record is inserted and in every > > >> >> >> >>> record > > >> >> >> >>> update, it would be this column updated. > > ... > > read more »
