On Tue, Apr 14, 2009 at 11:18 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> but the user can already define its own
>
> parse(text)
>
> and use it
>
> db.define_table(*parse(text))
Hmmmm.... not pre-this discussion. Anyway, if you are talking about parsing
to create one string so that your chosen solution is in gluon, then
technically you are right. More to the point, you can NOW do this - parse a
single string to create the equivalent SQLField calls for define_table()!
> I am talking about *forcing* a new syntax to our users instead of
> having everybody come up with their own shortcuts.
ugh!
We are talking about the same thing - only I want per-field syntax to be
defined, and you want per-table - at the gluon level, this is the only
difference.
Per table, I argue, is too brittle, over-specified; I argue that per-field
is the natural choice for this; you disagree.
IF you really want to "force" this ("no choice"), then you do you want to
drop SQLField and db.Field too?
> The solution I propose introduce a simpler syntax to define tables and
> set defaults.
No difference in simplicity between what you suggest (per table) and what I
suggest (per field tokens); in fact, I think per-field is simpler for a
broader range of uses - you see this simplest for your intended use, but I
argue it will narrow the scope of uses (what I mean by "brittle").
>
> db.define_table('dog: name unique, owner person by name')
One parser for tables - more complex, more difficult to define and explain,
more difficult to validate, more difficult to change / extend (too coupled
of a design - and I don't see any compelling reason!) --- for me this is a
strong consideration. Perhaps you have defined a grammar to show that it is
extensible, maintainable. In such case, my concerns become weaker.
> The solution you propose allows users to do
>
> db.define_table('dog', 'name unique', 'owner person by name')
Yes - and ONLY this!
> db.define_table(parse('dog: name unique, owner person by name'))
Massimo - you are fishing for arguments, but your fishing hook still has
only a worm on it! :-) You can do this now - you are right, no reason you
cannot parse this string into a sequence of appropriate db.Field() calls
now.
> db.define_table(your_own_parser('dog: name unique, owner person by
> name'))
Of course, you do not need to type the calls literally --- you can do this
now; actually, you can do BOTH of these last two now --- so I do not see
any point here...
thus breaking what could be a new unified syntax into two levels where
> some of it is specified by web2py and some is left to the user.
I do not see substance backing this - your argument for the last 2 of your
three examples applies equally any web2py release, so it is merely an
emotional argument (not a technical one).
You are arguing for a new API for table definitions. I started by
questioning the granularity of it. The 2 ways to define fields NOW is
already not clear to web2py group ("Massimo - why do you use db.Field() and
not SQLField()? What is the difference? When do I use which?" --- you will
now add a third option; let's not build a PERL!).
> moreover what now was implemented by only defining only one private
> function called only by define table, would become something more
> pervasive, requiring to change define_table, the constructor of the
> SQLField objects and require one exposed function.
I do not understand why you bring in changing the constructor of SQLField
objects or exposing functions --- I would merely cut by 1/3 or more what you
already have in autofields(), no more than you have (only less), and leave
the table-naming login in one place (take the duplication out of
autofields()). No more. Maybe not even that.
You added a private call to define_table; my suggestion only simplifies it.
What I am suggesting is precisely less pervasive - but the least pervasive
of all would be .... this has already turned un-interesting for me, not
based on technical merrit, so I will not fuel that...
Clearly, you REALLY want what you want. Fine. I have argued that it's too
rigid from one perspective, and offered an alternative. I could also argue
that it's superfluous, but am less convinced (haven't thought about that).
I sort of like this suggestion, and am trying to understand what
interesting uses / possibilities it might open. In thinking that, I see
problems with the single-string concept getting buried down into gluon.
I cannot change how you think or see things. I can only tell you what I
see, why I think what I think.
Kind regards,
Yarko
>
>
> Any other options on this matter?
>
> Massimo
>
>
> On Apr 13, 7:22 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> > On Mon, Apr 13, 2009 at 7:04 PM, Yarko Tymciurak <yark...@gmail.com>
> wrote:
> > > On Mon, Apr 13, 2009 at 5:28 PM, mdipierro <mdipie...@cs.depaul.edu
> >wrote:
> >
> > >> I can see lots of typos in people trying to do
> >
> > >> db.define_table('name','name string','birthdaty datetime')
> >
> > > Well - if the main goal is to have people type less, then this is not a
> > > problem - can do this from an application / user interface;
> >
> > > If this is a way to store a table definition on GAE, then this doesn't
> > > matter;
> >
> > > If this is a way to allow people to write programs (easily) to define
> new
> > > tables (think of an issue tracking system, for example, where you can
> create
> > > a tracked project, and describe custom tables) then this (multiple
> strings
> > > vs. one string) is probably a better solution.
> >
> > > In any case, I'm not arguing for what you want - but your arguments are
> > > "all over the place" - people typing; GAE storing....
> >
> > > I am arguing that all of these are possible, and have an appropriate
> place
> > > - and that the CORE (gluon) level should be to handle PROGRAMMATIC
> INPUT
> > > which is easily derived from user input (thru a controller), or easily
> > > coalesced into whatever you may want for GAE storage of table
> meta-data.
> >
> > > I think that is what is at issue here - one of abstraction level, and
> which
> > > is the right place to put what.
> >
> > If you add all the "kinds of things" --- GAE, user easy typing,
> > programmatic table generation - the one thing they all have in common is:
> > some text notation to describe a field. (Also, all the kinds of
> > applications / use cases you haven't thought of yet would have this in
> > common).
> >
> > It is this common factor that belongs being handled in gluon.sql - not
> > application / use-case level stuff. That's what I am saying.
> >
> >
> >
> > >> vs
> >
> > >> db.define_table('name: name string, birthdaty datetime')
> >
> > >> I think we can support both notations. What do you think?
> >
> > > See my comments above. If you support both at the GLUON level, then I
> > > argue you will have code bloat, and one piece that will be used by ....
> you?
> > > classroom? people on the list who will ask you to make modifications,
> > > instead of writing controllers / user interfaces / logic themselves?
> .....
> > > in other words, I think it's possibly but now how I would do it.
> >
> > ..._not_ how I would do it. And more, I suggest (rather strongly)
> against
> > the way you are proposing because I think it will reduce (rather than
> > increase) uses, reliability, etc.
> >
> > > 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.
> >
> > > Correct - and my point was --- what do you care if
> >
> > Maybe it would be clearer to you if I said, for this application you put
> > forth, what do you care if you have:
> >
> > - db.define_table(table.shorthand_string) # where gluon.define_table
> > calls yet something else to parse, which application writer cannot
> ....
> > CANNOT ever modify or change (e.g. result is something overspecified
> by
> > web2py!!!!)
> >
> > or:
> >
> > - db.define_table(parse( table.shorthand_string)) # you can provide
> > default parser at app level; I can write my own, but point is:
> > gluon.define_table only deals with the common denominator: a token
> > pattern for describing one field, and no more. That is well defined,
> > easily extended by web2py, and leaves appropriate flexibility at
> application
> > level.
> >
> > - Yarko.
> >
> >
> >
> > > - you provide a string, which then a gluon-level ("don't ever change
> > > because of backward compatibility!!!") function will parse (and
> this will
> > > be brittle, because you cannot change or add without all the "usual"
> > > concerns, so why do this at all?)
> > > - or you provide a "standard" contributed function which at
> application
> > > level will parse
> >
> > > In other words, the only thing that belongs in gluon.sql parser is for
> > > single field definitions - write a grammer to handle that, and that's
> the
> > > appropriate level for gluon.
> >
> > > Anything else YOU want (eg. one strting) can be processed at
> application
> > > level to easily give the gluon functions the basic tokens.
> >
> > > This also leaves the door open to other kinds of uses which are the
> same
> > > KIND of thing - like programmatic generation of table descriptors, user
> > > interfaces for users to define tables, etc.
> >
> > > This is the better approach. (This is my strong argument).
> >
> > > Make sense?
> >
> > > Regards,
> > > Yarko
> >
> > >> Massimo
> >
> > >> On Apr 13, 3:49 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> > >> > On Mon, Apr 13, 2009 at 2:11 PM, mdipierro <mdipie...@cs.depaul.edu
> >
> > >> 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 <yark...@gmail.com> wrote:
> > >> > > > On Mon, Apr 13, 2009 at 1:53 PM, Yarko Tymciurak <
> yark...@gmail.com
> >
> > >> > > wrote:
> > >> > > > > On Mon, Apr 13, 2009 at 1:40 PM, Yarko Tymciurak <
> > >> yark...@gmail.com
> > >> > > >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
> >
> > ...
> >
> > read more ยป
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
