Because I think if you have a table1 that reference a table2 and a
table2 that reference table1 something is wrong. I am not even sure
all the database backends support that. think about it, you cannot
insert a record in table1 without the record in table2 to reference
and vice versa. The proper way to handle this is to have a table that
links table1 and table2.
Anyway you can still do things like
db.define_table('person',
Field('username', 'string'),
Field('image', 'integer'), # a forward reference to db.image
)
db.define_table('image',
Field('image', 'upload'),
Field('owner', db.person))
db.person.image.requires=IS_EMPTY_OR(IS_IN_DB(db,'image.id'))
db.person.image.represent=lambda id:
A('link',_href=URL(r=request,f='download',args=db.image[id].image))
On Jun 15, 10:24 pm, Yarko Tymciurak <[email protected]>
wrote:
> On Jun 15, 1:56 pm, zsouthboy <[email protected]> wrote:
>
> > Hi Yarko,
>
> > Thanks for the help!
> > I had initially tried doing what the introductory docs show (which is
> > marking a reference like ("image", db.image) for a column), which
> > fails because there is no member 'image' of db yet.
> > Then I consulted the technical docs and saw that instead "reference
> > image" should be used instead, so tried that, thinking that it would
> > be used as a placeholder (and filled in correctly later).
> > When that failed, I posted here.
>
> > The DAL doesn't recurse to allow this situation? Does anyone know
> > why / why not? When I get a chance I'll look at gluon and see how
> > trivial it would be to do, even in a hacky way.
>
> ... consider dropping this from your vocabulary: ".... even in a hacky
> way...";
>
>
>
> > I do have a separate issue now: following what you've suggested, I now
> > get complaints from gluon that referenced tables have duplicate field
> > names as the table being defined - did I miss something obvious? That
> > seems like there should be no issue doing so. (you can get this error
>
> Yes, it seems so: in gluon/(dal|sql).py, in
> Table._create_references(), there's:
>
> if self._tablename in referee.fields:
>
> with no comments - so beyond the shallow, immediate reading for that
> line, we have no clue
> as to the motivation / reasoning for this particular constraint
> (reverse engineering every little thing
> just to try to get what intended... besides being no better than
> guessing, mind-reading,
> also gets tedious). If you simply rename db.person.image to
> something w/o the 'image' (tablename),
> e.g. db.person.image_id --- this goes away.
>
> As to forward references:
> I commented out the lines in Table._create_references() (and the
> exception it raises), and __get__ errors come, so there is at least
> that simple get/set work to do to get forward references; not sure if
> there would be anything else. Commented code _sure would be nice_!
>
> - Yarko
>
> > by simply copying and pasting the suggested fix you responded to me
> > with into a test db.py, even). Duplicate field names, but they're in
> > separate tables, so why the error?
>
> > Traceback (most recent call last):
> > File "gluon/restricted.py", line 178, in restricted
> > exec ccode in environment
> > File "/var/www/web2py/applications/golb/models/db.py", line 93, in
> > <module>
> > Field('published', 'boolean'))
> > File "gluon/sql.py", line 1304, in define_table
> > t._create_references()
> > File "gluon/sql.py", line 1579, in _create_references
> > raise SyntaxError, 'Field: table %s has same name as a field in
> > referenced table %s' % (self._tablename, referee._tablename)
> > SyntaxError: Field: table image has same name as a field in referenced
> > table person
