There are many problems I can detect in this solution:
1. It is a code-generator - I was aiming for a file-format parser that
implements the code, not generate it, and one that is built-into the DAL
constructor, and uses conventions. I don't really care for
auto-generated-comments, but I would like to be able to just include a line
like:
db = DAL('db')
and then have the constructor look for a file named "db.schema.yaml" or
something - then pars it while executing the necessary directive on the
spot.
There shouldn't be any declerative code at all - it is not needed - code is
for imperative processing - not declerative.
2. It does not adhere to any standard that has support for in existing
database-schema visual designers that have a node-based GUI.
This goes with the first point - the goal should be to not have to deal
with code at all when designing the database, as again - that is a
decorative process, not an imperative one... By having the entire DAL
definition completely declarative, you can just use a GUI tool of your
choice for schema design. It can then also enable web2py to come built-in
with its own web-based application and/or appliance within the admin
application, to use for managing database schemas visually for the hosted
applications.
3. It is old and deprecated - it uses SQLFIELD...
4. The way "db" is at the same level in the hierarchy as the tabled is
un-intuitive
On Sat, Feb 2, 2013 at 1:06 PM, Jose <jjac...@gmail.com> wrote:
>
>
> El sábado, 2 de febrero de 2013 13:30:49 UTC-3, Arnon Marcus escribió:
>
>> It may be not directly related to this topic, but I have been thinking
>> about this for a long time now:
>> Writing database schemas in python in the model is very simple and
>> decorative.
>> Why not make it a declarative format?
>> This way, it can be designed and updated with this kind of GUI tooling,
>> as a 2-way binding.
>> This can even be layered on-top of the currently existing pythonic-way of
>> writing it, using a simple parser.
>> It's just a matter of choosing a declarative format/protocol - preferably
>> something SQL-related and open standard.
>> I am unfamiliar with this field, but I am sure there are many such
>> formats that already exist.
>> This way, the schema can even be edited in whatever other external tool
>> that supports that format.
>>
>> Just as an example, a GUI graphical designer could produce something like:
>> "
>> <--! db.xml -->
>> <database name="MyDatabase" port="5432" type="postgres" user="postgres"
>> host="myhost">
>> <table name="MyTable">
>> <field name="MyField" type="string">
>> </table>
>> </database>
>> "
>>
>> And then this can be used in the model as such:
>> "
>> ...
>> # prepare a 'databases' list from the xml document that was parsed
>> ...
>> for database in databases:
>> db = DAL()
>> ...
>> # prepare a 'tables' list from the 'database' node's children...
>> ...
>> for table in tables:
>> fields = []
>> ...
>> # prepare a 'tableFields' list from the 'table' node's children...
>> ...
>> for tableField in tableFfields:
>> ...
>> # convert the tableFiled node into a dictionary with it'sattributes
>> ...
>> field = db.defineField( tableField['Name'], tableFiled[''type'] )
>> fields.append(field)
>>
>> db.defineTable(table['name'], fields)
>> "
>>
>> This can be further integrated into the DAL class itself, of course...
>>
>
> It exists [1]
>
> Jose
>
> [1]
> https://groups.google.com/forum/?fromgroups=#!topic/web2py/DdS31FtNCjc
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
