On Mon, Apr 13, 2009 at 1:53 PM, Yarko Tymciurak <[email protected]> wrote:
> 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'] > Note this also can free up other things: ":" can now be a separator (so spaces in validators can be used), e.g.: dyna_fields=['name', 'birthday: date', 'some_comment: text: default string'] I think this opens the possibility for more "regular" processing, and broader ways of generating tables. What do you think? - Yarko (... still thinking about this...) 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 -~----------~----~----~----~------~----~------~--~---
