Perhaps I do not understand the question. If you add a field you know you are adding it. If you need to initialize it with a function then you have to loop over all records and to an update_record. Are you trying to prevent the update from accidentally happening twice?
Massimo On Oct 5, 6:26 pm, Scott Hunter <[email protected]> wrote: > Thanks for the quick reply! > > The situation I'm interested in is where the field doesn't exist and > I'm adding it as a UNIQUE field; v1.65.10 generates a ticket when the > appliance starts up, saying it can't add a UNIQUE field, which seems > odd, since field creation is pretty much the only time you're assured > there would be no conflict. > > I may be mistaken about being able to add UNIQUE=true once the field > already exists. I'll check out the latest version, and see if that > addresses the issue. > > Any ideas about the initialization questions? > > - Scott > > On Oct 5, 5:45 pm, mdipierro <[email protected]> wrote: > > > I believe something has changed about this since 1.65.10 so you may > > want to look at a more recent version (1.86.2 has lots of bug fixes). > > I do not remember exactly the details about what changed in this > > respect. In general the problem is that if you make a field unique, > > after there is data in it, web2py has no way of knowing if the data > > already in was unique or not and there is no easy way of checking. > > > On Oct 5, 4:13 pm, Scott Hunter <[email protected]> wrote: > > > > 1) I want to let migration add a UNIQUE=true field to a table, which > > > apparently isn't allowed. But what does seem to be allowed is having > > > the field added w/ UNIQUE=false, and after restarting the server (now > > > that the field exists), having UNIQUE=true. Is there a way to > > > accomplish this w/ the restart? > > > > 2) Related to the above, is it possible to detect when this field will > > > be added, so that I can initialize it? Unfortunately, it has to be > > > computed, so unless default can be a function that gets called (it > > > wouldn't need any arguments), I don't see how this could be done. > > > > 3) s there a way to tell when a define_table has to actually create > > > the table, so I can stuff in an initial record? I suppose I could do > > > a query after the definition, but then it will get done for every > > > request. > > > > Thanks in advance, > > > Scott Hunter > > > > P.S. I'm currently using v1.65.10; if a newer version would help > > > address any of these, that'd bolster my argument to upgrade! > >
