Thanks for the info, this is exactly what I wanted!
This seems to violate one of the basic principles of python
programming philosophy: "There should be one--and preferably only one--
obvious way to do it."
In fact, this particular example demonstrates precisely why that rule
of thumb is a good one -- here we have two ways to do the same thing,
but one way works in places where the other doesn't, so we really need
to learn *both* ways. (Actually, maybe we only need to learn the more
powerful latter method... but the former method, with weaknesses, is
the one taught first in the web2py slideshow.)
Are there any advantages (other than saving a few characters) to
writing db.other_table instead of "reference other_table"? If not,
maybe it should be deprecated? (Not removed, I know backwards
compatibility is important... but at the very least, relegated to an
appendix in the documentation instead of being the preferred method).
On Jul 21, 11:49 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> There are two formats for declaring a reference:
>
> ....
> db.Field('owner', db.other_table) # this must have other_table already
> defined, or it is a Python error;
> ...
> db.Field('owner', 'reference other_table') # this is delayed evaluation,
> and what you would use to have two tables cross link each other;
>
>
>
> On Tue, Jul 21, 2009 at 10:27 PM, JoshuaJ <surely.you.j...@gmail.com> wrote:
>
> > It seems that in web2py, if one table is to have a foreign key to
> > another table, the target table must be defined first in db.py. Does
> > this mean that there is no way to have two tables that link to each
> > other?
>
> > Specifically: I'm writing a basic multi-user address book application.
> > Each user, of course, owns multiple contacts. However, each user
> > selects at most one of their contacts as being their identity, the
> > contact that represents themselves.
>
> > The way I'd do this in a traditional database would be to define a
> > "users" table with fields "username" (a string) and
> > "primary_contact_id" (foreign key into contacts table); and then a
> > "contacts" table with fields "contact_data" (i'm simplifying here) and
> > "owner_id" (pointing back into the users table). However, Web2py
> > doesn't seem to allow this.
>
> > Does anyone have a solution?
>
> > (One workaround would be to add an "is_identity" field to each
> > contact, but this seems like a nasty kludge, firstly because since it
> > will have the value of "no" for the vast majority of contacts, but
> > more importantly because it doesn't guarantee data integrity -- a bug
> > in the code could leave a user with multiple identities, something
> > impossible with the other representation.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
