Since the Reference object now will query for a reference record when
you call it, you can do things like::
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.
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".
--
Thadeus
On Sat, Apr 24, 2010 at 10:24 AM, DenesL <denes1...@yahoo.ca> wrote:
>
> On Apr 24, 9:11 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>> I think there is said to say pro and con this convention.
>>
>> case1)
>> db.define_table('person',Field('name'))
>> db.define_table('dog',Field('name'),Field('owner_id',db.person)
>>
>> db.god.owner_id makes sense because it stores an integer but
>> db.dog.owner_id.name is odd because 'name' is not n attribute of an
>> id.
>
> The convention makes more sense when you use the same name:
> db.define_table('dog',Field('name'),Field('person_id',db.person)
>
> Since you are using 'owner' (an unique field name) then there is no
> need to append id, but owner_id immediately suggests what type of
> field it is and it can avoid a possible clash in request.vars with
> another field when things get more complicated (more tables and
> fields).
>
>> case2)
>> db.define_table('person',Field('name'))
>> db.define_table('dog',Field('name'),Field('owner',db.person)
>>
>> db.god.owner technically stores only an id
>> db.dog.owne.name to me is better than db.dog.owner_id.name
>
> Maybe you meant db.person[owner].name
> but either db.person[person_id].name or
> db.person[owner_id].name are perfectly readable,
>
> db.dog.owner.name is just the name of the field ('owner').
>
> Even though it might not be perfect it seems like a good idea.
> Anyway, I would like to hear what others do.
>
> Denes.
>
>
> --
> Subscription settings: http://groups.google.com/group/web2py/subscribe?hl=en
>
