Note you can do such query :
db(db.table.id > 0).select("sql_field_name AS new_sql_field_name") but I
don't recall how you access value of a field query like that (plain sql
passed into select...) You can experiment... There is a presentation from
Anthony Bastardi about these undocumented feature
Thank you for your reply, Richard!
" a normalized way to represent web2py list:reference field with a proper
many-to-many relation table " - yes! this is what I meant, 'alias_name' -
just very bad example of field name - it isn't about aliasing - sorry for
the mess
About views
I think I found
Hello Val K,
I am not sure I understand fully what your are talking about. On one hand,
I do understand that you would like a proper way to define SQL VIEW in
web2py and you propose to add a switch/flag/argument to define_table() to
do so, which would result in a select only table or something lik
It doesn't differ from reference fields. it is about automation distributed
transaction.
Table 'person' hasn't Field('alias_name' ) at db level, it's fake Field
with reverse reference declaration ( 'storedin alias_opt.alias_name' ) that
defines table.field that would be really involved in CRUD-
On Tuesday, December 6, 2016 at 3:41:38 PM UTC-8, Richard wrote:
>
> UP, never get any answer...
>
How would this differ from reference fields?
/dps
>
> On Sat, Jan 23, 2016 at 4:08 PM, Val K >
> wrote:
>
>> Hi guys!
>> I have an idea to improve DAL in scope of work with normalized DB.
>> As
UP, never get any answer...
On Sat, Jan 23, 2016 at 4:08 PM, Val K wrote:
> Hi guys!
> I have an idea to improve DAL in scope of work with normalized DB.
> As known It's a common practice to avoid NULL value by creating separate
> (option) table(s) to store non required fields.
> So, it would be
6 matches
Mail list logo
