>2010/10/3 mdipierro <mdipie...@cs.depaul.edu>
>
> ... but SQLFORM and web2py crud will not work with sqlalchemy.
>
> one reasons we cannot do something like SQLAlchemy's reflect in web2py
> is that the database is not aware of how web2py should treat the
> field. For example a 'varchar' field could be a 'string', a
> 'password', an 'upload', or a 'list <something>'. The db does not know
> so in web2py you have to declare (define_table) it.
My idea is to create a 'database centric' webapp. A webapp that you
can slap on a legacy db(mysql for now) with minimal effort.
Requirements:
1. db is schema is a set of SQL commands
2. webapp shell autoload the schema and use
tables
field types
field relations
3. the autogenerated webapp model shell name tables/fields exactly as
in the db schema
4. the model shell be manually customisable to add information absent
in the scheme(like foreign keys in MyISAM tables)
5. the model shell permit to create virtual tables from fields of real
tables WITHOUT mapping tables to classes to assist unify interface to
different but similar databases and to create 'views' composed from
fields of different tables.
6. virtual tables shell be CRUDable
7. the model shell be reusable with different web frameworks so as
much code as possible in the model.
Requirements 1,4 are to let DBA and programmer think in same terms and
avoid situations like:
DBA - your program is producing crazy queries! You sort on field
'somefield' and its a BLOB!
programmer - in my ORM 'somefield' is a password.
DAL is almost up to the requirements.
Its only real problem is the 'id' field issue but I can't fix it and
SQLAlchemy(SA) offers so much more for legacy db.
> ... but SQLFORM and web2py crud will not work with sqlalchemy.
maybe we can have another db adapter that doesn't issue SQL but calls
SA functions?
>the database is not aware of how web2py should treat the field.
It wold be relatively easy to add this information to the model manually
OR we can put this information in the scheme comments like tis:
CREATE TABLE testing (
name VARCHAR(5)
) COMMENT='field=web2pytype';
OR automatically derive this from field name. Any way SQLFORMs will
deal mostly with 'virtual view tables'(see requirement 5) so we will
be able to name field to specified convention
OR(IMHO the right way) store this information in a separate table
editable with the webapp. This will help in slapping the webapp on a
db. Just autoload the scheme, check generated model for relations, add
virtual view tables, go to web page to fill in SQLFORMs type
information from a drop list...
Maybe relations and virtual tables are also to be stored in a webapp
editable tables?
That would allow 0 coding legacy db CRUD...
