On Apr 24, 1:34 pm, DenesL <denes1...@yahoo.ca> wrote: > 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.
Yes - and you've clarified well - it is the "symbol table" vs. simple string representation of a field, and the ambiguity that involved... (I was referring to Massimo's objection - and am with you; the naming is whatever works for you; for Massimo, I wanted to suggest de- coupling his view from "id" as an automatic field, and look at the naming solution as one that suggests an indirection - whatever way you find clear). > > > 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. Exactly - an indicator to "the humans" that this is not a normal field, but a reference field (too bad we can't use the C notatoin of "*owner" ! ... just kidding... partially...) > > > 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! Exactly > 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. RIght! > 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. Yes - and that is the motivation for making field names more indicative, partly to help human-hinting at what you are looking at, and partly to avoid clashes like this (which will not occur everywhere, which is why - generally - unique filed naming is not generally important / an issue). > > Denes. > - Yarko > -- > Subscription settings:http://groups.google.com/group/web2py/subscribe?hl=en
