On Apr 24, 12:06 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > in quickly scanning this thread, I am struck by a few observations: > > - it is useful for the human reading to have a hint that a variable is > an 'indirect" reference; > - the specific details - that the inderection is by a table index > called "id", and that it is an integer seems irrelevant (even, if at > first convenient); > - the "naming sense" and discussions seem to have tripped over the two > preceding observations. > > To wit: consider (using Massimo's example): > > db.dog.i_owner.name
db.dog.i_owner.name == 'i_owner' db.dog.owner_id.name == 'owner_id' db.dog.owner.name == 'owner' and it has nothing to do with the issue. > It reads as _well_ as db.dog.owner.name, while addressing what Denes > points out: readability, and "hint" to the code reader that it's an > "indirect reference". > > I think it helps to forget about the literal reference to an "id" > field, and instead consider what kind of thing it represents (i.e. > focus on the abstract concept, not the specific implementation > detail). On the contrary, using '_id' helps me to relate it to the web2py field type being used and therefore the concept behind it. But again, you can use whatever convention you like as long as it keeps the names unique. > The last observation I have: naming conflicts / ambiguity: this > (correct me if I missed something) is not about naming comflicts, as > these are not variable names / scopes, but rather strings being > interpreted "in the absense" of a traditional symbol table, etc. --- > this is a good reason to heed Denes's warning to keep names separate: > that is, note that much of what is manipulated in Fields, queries is > (in fact) strings which are later converted to specific SQL. Lets use the 1st post by Annet as case study. She had an 'application' table with an 'application' field. She also had a 'companyapplication' table with an 'application' field. Since she wanted the entries in 'companyapplication' table to be unique she used this requires: IS_NOT_IN_DB(db(db.companyapplication.application==request.vars.application),db.companyapplication.company) A request to add a new entry in table 'application' will have a request.vars.application, which a request to add a new entry in table 'companyapplication' will also have. That is the problem! It is a field naming problem. When the requires is checked there is no way to know which 'application' is request.vars.application referring to. It should be the one in table 'companyapplication' obviously, but request.vars does not know which fields belong to which table. I hope this clarifies the issue. Denes. -- Subscription settings: http://groups.google.com/group/web2py/subscribe?hl=en
