I can see lots of typos in people trying to do
db.define_table('name','name string','birthdaty datetime')
vs
db.define_table('name: name string, birthdaty datetime')
I think we can support both notations. What do you think?
This comment:
> for table in db(db.meta.id>0).select():
> db.define_table(table.shorthand())
I did not understand. table here is a record and table.shorthand would
be a string value.
Massimo
On Apr 13, 3:49 pm, Yarko Tymciurak <[email protected]> wrote:
> On Mon, Apr 13, 2009 at 2:11 PM, mdipierro <[email protected]> wrote:
>
> > I agree that the syntax you propose is cleaner but why are we doing
> > this?
>
> > For me the reason is move functionality out of T3.
>
> Ok.
>
> > In particular we need a way to store a model in another model (think
> > of a table of table descriptions) in order to be able to create models
> > on GAE without going through the local development environment. The
> > shorthand notation for me is just a bonus.
>
> > Having the entire table represented as a single string accomplishes
> > this:
>
> > for table in db(db.meta.id>0).select(): db.define_table
> > (table.shorthand)
>
> Ok - but you are still talking higher level functionality here (single
> string);
> What do you loose from this:
>
> for table in db(db.meta.id>0).select():
> db.define_table(table.shorthand())
>
> Nothing - it's just a matter of how much you push down into the core.
> Putting _too_ much higher level assumptions low just blocks other, similar
> (or unanticipated) uses.
>
> ['table_name', 'field_name:field_type:field default'] ==> "table_name;
> field_name:field_type:field default;"
>
> Put another way, you are pushing a particular persistent storage issue down
> into gluon (wanting a single string) - I question this.
>
> There are numerous ways to store, so being explicit about what _kinds_ of
> uses you are targetting is important. You have stated one (and until now,
> at least on this thread and in the code, it has been implicit; it's good to
> make it explicit).
>
> In any case, if you intend to write a single blob, it would be good exercise
> to implement a parser, and then think about where each piece belongs. (this
> actually looked interesting, as I scanned for parser
> generators:http://www.acooke.org/lepl/) <http://www.acooke.org/lepl/>
>
>
>
> > Massimo
>
> > On Apr 13, 1:59 pm, Yarko Tymciurak <[email protected]> wrote:
> > > 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
-~----------~----~----~----~------~----~------~--~---
