On Mon, Apr 13, 2009 at 1:40 PM, Yarko Tymciurak <[email protected]> wrote:
> I have a couple of immediate comments:
> [1] - with this syntax, you do not process and fields or migrate statements
> (but you _could_; suggest you do)
> [2] - the autofields() function seems to mash concerns in other ways also:
> it handles tablename update (? why here) in addition to "autofields"; for
> one thing, it does NOT do cleanup() (as define_table otherwise does) - this
> is the beginnings of handling things differently in different conditions
> (and a typical symptom of blurred boundaries of concerns).
>
> Suggest you DO table name handling in _one place_, and field processing (as
> you have) in one place, and consider that you only ADD "autofields" as a new
> syntax for defining fields.
>
> Having said that, it occurs to me that a comma separated text string is
> just one layer of this, and it would be good to split this out, so that
> web2py application developers could create things more automatically, to
> wit:
>
> [3] in sql.autofields() ==> for field in fields.split(',') ---- I would
> make this do NO MORE than call an individual field processing function
> (separate this functionality)
>
> [4] I would add / allow a list to be passed (that is, allow the
> application developer to _already_ have split the field definitions to "the
> new text specification format") --- this will be much handier for automated
> processing. There are a couple of ways you could handle this, one being
> parsing *fields in define_table() to first split them out to string (or
> list?) vs. function types, process all the string types by some
> autofields_parse() function, collect and pass the rest to SQLTable(self,
> tablename, *fields)...
>
... as I think of this, and of application developers I would ONLY process
lists for the "new" syntax - there is no useful reason to have a string that
the CORE then splits on ',' and only complicates the core.... this is the
kind of niceity that better belongs at the application level - either for
the app writer, or in an admin (or other higher level function).
So I now would prefer to see *fields argument to define_table() handle all
field definitions, and based on type of ...field in fields'... I would
collect them and process accordingly. If you _really_ want, you could
insist that the fields list passed to define table be already coalesced
(this would simplify core) - that is, all of one together, so that a change
is assumed to apply to rest of fields (I think this is prefectly
reasonable)....
So you see what I am proposing, I would do something like:
db.define_table('mytable',
'name',
'birthday date',
SQLField( 'some_other_field', 'integer', default=foo()),
# and all the following are now assumed to be function calls
)
or, alternatively:
dyna_fields= ['name', 'birthday date']
db.define_table('mytable, *dyna_fields,
SQLField( # and so forth....)
)
- Yarko
>
> Make sense? I think with a little finesse this could provide more than a
> "nice syntax", rather a handy way to automatically generate tables from
> descriptors.
>
> Regards,
> - Yarko
>
>
>
> 2009/4/13 mdipierro <[email protected]>
>
>
>> Try latest trunk. You can do:
>>
>> db.define_table('friendship: person by name birthday notnull, dog by
>> name ')
>>
>> mind that you cannot have both notnull and unique and you cannot have
>> a unique reference because I just realized we lack a validator to do
>> it. I will make one and extend this..
>>
>> Massimo
>>
>> On Apr 13, 12:26 pm, mdipierro <[email protected]> wrote:
>> > Actually it does just
>> >
>> > db.define_table('friendship'
>> > ,SQLField('person_name')
>> > )
>> >
>> > but I am about to follow your suggestion (with a slight change in
>> > notation) and do
>> >
>> > db.define_table('friendship: person by name birthday notnull, dog by
>> > name ')
>> >
>> > generate:
>> >
>> > db.define_table('friendship'
>> > ,SQLField('person',requires=IS_IN_DB(db,'person.id','%(name) %
>> > (birthday)',notnull = True),
>> > ,SQLField('dog',requires=IS_NULL_OR(IS_IN_DB(db,'dog.id','%
>> > (name)')),
>> > )
>> >
>> > Massimo
>> >
>> > On Apr 13, 11:13 am, DenesL <[email protected]> wrote:
>> >
>> > > Maybe too short to be useful, but when you get to references it would
>> > > be nice to have:
>> >
>> > > db.define_table('friendship: person.name, dog.name')
>> >
>> > > But then, does this mean:
>> >
>> > > db.define_table('friendship'
>> > > ,SQLField('person_name'
>> > > ,db.person
>> > > ,requires=IS_IN_DB(db,db.person,'%(name)')
>> > > )...
>> >
>> > > or
>> >
>> > > ,SQLField('person_name'
>> > > ,db.person.name.type
>> > > ,db.person.name.length
>> > > ,requires=IS_IN_DB(db,db.person.name)
>> > > )...
>> >
>> > > On Apr 13, 2:16 am, mdipierro <[email protected]> wrote:
>> >
>> > > > In trunk you can now do
>> >
>> > > > db.define_table('person : Name, Birthday date, Telephone')
>> > > > db.define_table('dog: Name, Owner person, Picture upload')
>> >
>> > > > Is this useful? Look at the source. Is the syntax reasonable?
>> >
>> > > > Massimo
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
