Table shortcuts

[Álvaro Justen [Turicas]]

Hi,
sometimes we use prefixes to identify tables, like:
myapp_mytable
I use it because I have only one DB per site - and one site can have
multiple apps.
But is very painful to do db.myapp_mytable.somefield.
So, I request a new feature:
db.define_table('myapp_mytable',
shortcut='mytable',
SQLField(...),
...
)

So I can use both db.mytable and db.myapp_mytable.
Ok, I can do:
db.mytable = db.myapp_mytable
But it don't work in SQLRows when I search more than one table.

Massimo, what do you think?

--
Álvaro Justen
Peta5 - Telecomunicações e Software Livre
21 3021-6001 / 9898-0141
http://www.peta5.com.br/

[mdipierro]

More than this I would prefer to have

db.define_table('mytable',
> SQLField(...),
> ...
> actual_filename='myapp_mytable',
> field_prefix=None',
> )

The problems are:
- This requires many small changes to sql.py and, if done, needs to
lots of testing.
- This requires introducing one more lookup table to map real name
into virtual names and it will slow down the building of sql
expressions
- So far we tried to be as close as possible to the actual DB. This
would be a (minor) change of phylosophy.
- If done, this has to be done for gql as well.

I think this should be done by only as part of a major more modular
refactoring of sql.py. If we hack this in sql.py will become too
complex to manage.

Massimo


On May 11, 9:20 am, Álvaro Justen [Turicas] <alvarojus...@gmail.com>
wrote:

[Álvaro Justen [Turicas]]

On Mon, May 11, 2009 at 12:33 PM, mdipierro <mdip...@cs.depaul.edu> wrote:
>
> More than this I would prefer to have
>
> db.define_table('mytable',
>>     SQLField(...),
>>     ...
>>     actual_filename='myapp_mytable',
>>     field_prefix=None',
>> )
>
> The problems are:
> - This requires many small changes to sql.py and, if done, needs to
> lots of testing.
> - This requires introducing one more lookup table to map real name
> into virtual names and it will slow down the building of sql
> expressions
> - So far we tried to be as close as possible to the actual DB. This
> would be a (minor) change of phylosophy.
> - If done, this has to be done for gql as well.
>
> I think this should be done by only as part of a major more modular
> refactoring of sql.py. If we hack this in sql.py will become too
> complex to manage.

I think it is not so complex. What if we modify SQL to "SELECT ...
FROM tabel AS my_new_name"? The problem is that I don't know GQL... is
there a "AS" like in SQL?

[mdipierro]

No that is not an option since that mechanism is already used for
complex joins.

Massimo

On May 13, 4:32 pm, Álvaro Justen [Turicas] <alvarojus...@gmail.com>
wrote: