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
