define_table - how to do this correctly (best practice?)

[lyn2py]

I have tables with individual properties,

db.define_table('article',
Field('title', 'string', length=255,required=True),
Field('description', 'text',required=True),
)
db.define_table('post',
Field('title', 'string', length=255,required=True),
Field('description', 'text',required=True),
)
db.define_table('page',
Field('title', 'string', length=255,required=True),
Field('description', 'text',required=True),
)

And I have a table with many-to-many relationship (with different
tables):

db.define_table('action',
Field('user_id','reference
auth_user',default=auth.user_id,required=True),

Field('action','string',requires=IS_IN_SET(('fav','subscribe','report','follow')),required=True),
Field('table',requires=???,required=True),
Field('table_id','integer',default=???,required=True),
)

My questions:
1.. The field, "table" is actually one of the tables, article/post/
page. Is the only correct way to use
requires=IS_IN_SET(('article','post','page')) ?

2.. "table_id" is actually dependent on the "table" selected. what
should I put for "default=???"

3.. Can I set a different set of IS_IN_SET for "action" field,
depending on the "table" field chosen?

4.. Finally, if the above is the wrong approach, how should I do it
correctly (best practice?)

Thanks!

[Andrew]

I think this is more of a data modeling question than web2py.
I would have one table called "content" with an extra column
"content_type" . You could define queries over the top if you just
want one ofthe three.

Your M:M table logically joins to "content". You sort of have three
subtype tables, but they are identical in structure so there is no
reason to separate,

On Jan 6, 5:22 am, lyn2py <lyn...@gmail.com> wrote:
> I have tables with individual properties,
>
> db.define_table('article',
>   Field('title', 'string', length=255,required=True),
>   Field('description', 'text',required=True),
> )
> db.define_table('post',
>   Field('title', 'string', length=255,required=True),
>   Field('description', 'text',required=True),
> )
> db.define_table('page',
>   Field('title', 'string', length=255,required=True),
>   Field('description', 'text',required=True),
> )
>
> And I have a table with many-to-many relationship (with different
> tables):
>
> db.define_table('action',
>   Field('user_id','reference
> auth_user',default=auth.user_id,required=True),
>

> Field('action','string',requires=IS_IN_SET(('fav','subscribe','report','fol low')),required=True),

[lyn2py]

What you say is true, however for argument's sake, how could I achieve
the above with the 4th table?

In my situation, the 3 tables have different fields (but I didn't have
access to the file so I simply made them the same in the example here.

Thanks.

[lyn2py]

Bump. Help anyone?

Can "default" be equal to a variable dependent on another field in the
same table?

Thanks!

[Anthony]

Can "default" be equal to a variable dependent on another field in the
same table?

I haven't looked at your original question in detail, but regarding the above question about defaults, no, they can't be dependent on other fields in the same table (though they can be dependent on request.vars, including request.vars that have been submitted to fill other fields in the table). An alternative is to set the "compute" attribute of the field, which can (and is intended to) depend on other fields in the table (see http://web2py.com/books/default/chapter/29/6#Computed-fields). You can insert a value directly into the field, but if no value is provided, it will compute a value according to the compute function. Note, by default computed fields are not shown in SQLFORMs, though you can explicitly list them among the fields to be shown.

Anthony 

[lyn2py]

Thanks Anthony, will look into the areas you mentioned! :)

On Jan 8, 12:35 am, Anthony <abasta...@gmail.com> wrote:
> > Can "default" be equal to a variable dependent on another field in the
> > same table?
>
> I haven't looked at your original question in detail, but regarding the
> above question about defaults, no, they can't be dependent on other fields
> in the same table (though they can be dependent on request.vars, including
> request.vars that have been submitted to fill other fields in the table).
> An alternative is to set the "compute" attribute of the field, which can

> (and is intended to) depend on other fields in the table (seehttp://web2py.com/books/default/chapter/29/6#Computed-fields). You can