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 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). 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. - Yarko On Apr 24, 11:45 am, DenesL <denes1...@yahoo.ca> wrote: > On Apr 24, 11:06 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > Since the Reference object now will query for a reference record when > > you call it, you can do things like:: > > What do you mean by 'now'? This has always worked for Rows. > > > dogs = db().select(db.dog.ALL) > > for dog in dogs: > > dog.name > > dog.owner.name > > > So the refernece column is actually called owner, insetad of owner_id. > > It doesn't make sense to do > > > ``dog.owner_id.name`` > > > Since the record gets pulled behind the scenes by web2py. > > The convention is used to avoid conflicts in request.vars and to make > it clear that it is a reference field. > If 'owner' is a unique name then using it is fine. > > However if you have 'owner' somewhere else along with a requires like > the one Annet had then there will be a conflict, since in request.vars > you can not tell them apart, i.e. when you say request.vars.owner you > don't know which one you are referring to because request.vars only > knows about field names and has no knowledge of the tables they belong > to. > > > However, even though this convention allows for a nice shortcut during > > development, it can easily get out of hand on production systems. For > > example, I have a patch on gluon.sql that keeps track of what kind of > > queries are being made and how many of them throughout the life of the > > request. Linking this with my blog, I end up with one page equals a > > total of 234 SELECT statements from the database. Its not cool, > > however with a little re-designing and I can bring it down to just a > > handful of selects by not taking advantage of this "convenience". > > You lost me here, I can't picture what you are doing. > > Denes. > > -- > Subscription settings:http://groups.google.com/group/web2py/subscribe?hl=en
