On Dec 11, 10:21 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Yarko,
>
> This feature as well as the new Keyed Tables (which do somewhat what
> you say) were proposed, implemented in trunk, and there was an RFC on
> this mailing list. They both made in trunk one month ago. I understand
> you do not like the syntax but you cannot complain about it now that
> it is done.
... I am merely commenting on what I saw in this thread, and raising a
suggestion that google code-review could be more useful than group
threads (and comments / decisions stay with revision history). I
hear that you think group / email threads are "good enough" - maybe
so, but I stand by my suggestion that this thread is evidence that the
code-review process in place on google code would be beneficial beyond
what was in place.
Perhaps you are right - perhaps "Field()" is appropriate here, even
though everything about it's handling is special (all the other field
options, as far as I can tell, do not apply).
I do see this was / is not clear on this thread, and the discussion /
decisions are not part of the repository (a benefit which google code-
review will add).
>
> I believe the current implementation is much cleaner than the one you
> propose, in fact it was implemented without creating any new API.
Perhaps; no new API either way... but your reply seems as if in
response to an offense... none intended;
> Unfortunately these features are only one month old therefore they are
> not in the book, need more testing and need more documentation.
Denes has documeted the items not documented in this list; the code-
review thing on google code would add a level of documetation too.
> The
> Keyed tables for now only form for some dbs. The functionality will be
> extended as needed by users while keeping the current syntax.
>
> There is no FNM (?!).
FMN - magic numbers; in CS it is something we graded down for
strongly in our University (of course, this was years ago);
What this refers to is constants used, where a "name" - an abstract,
descriptive form would serve better, and even more strongly where the
same constant was repeatedly used. There are _some_ cases where a
constant is clearer, and surely in Python so much is processed as
strings.
But in this case I specifically refer to a string - the SAME string -
where it is used in a multiple of ways, and thus is an example of the
intent of the term I fondly carry with me all these years from
University, "FMN" - that is, something that could be made clearer.
A simple grep for 'id' in gluon/sql.py shows it appears 40 times; of
this, it appears in a line where 'type' is somehow part of the line (a
use of the constant string which I would say is valid, and clear) all
of 7 times. That leaves 33 times where - upon perusing the code -
one is left to "parse" on their own: is this referring to the
definition of the field type? Is this a reference to the field type
in a DB backend descriptor? Is this looking for the field NAMED id?
In short, it is an example of why my professors even thought up the
term FMN - much like:
result = read.port[3]
is not as clear as (say)
result = read.port[USB_CHIP_SELECT]
These really are basics of communicating, I think - the "literature"
of coding.
> In fact the 'id' type always existed. The 'id'
> field has always been of 'id' type since web2py 1.0 in October 2007.
I understand. That is not what I am talking about. Your code has
'id' as the field type; 'id' as the field name, and possibly other
kinds of references.
>
> Massimo
>
> On Dec 11, 10:03 am, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> wrote:
>
>
>
> > On Dec 11, 12:41 am, Brian M <bmere...@gmail.com> wrote:
>
> > > t.staid could be the primary key as far as the database is concerned.
> > > The issue is that web2py expects the primary key field to be called
> > > ID.
>
> > > I'd give Massimo's suggestion of db.define_table(...Field
> > > ('staid','id'),...) a shot - he's the man, so he ought to know.
>
> > > Massimo - what exactly does Field('staid','id') do? Is that just
> > > telling web2py that field staid should be treated as the ID field? Is
> > > 'id' now a valid fieldtype just like 'string' or 'integer'?
>
> > This is probably another example where we would have benefitted from a
> > code review / design review.
>
> > "Field()" is constructor (manual, p.153), and used to define table
> > fields within the define_table constructor (the way that has been
> > web2py/DAL, in one form or another, "forever").
>
> > This is perhaps the first "special" form of "Field()", and the first
> > one to define default behavior of the "ID" field (which is why it is
> > natural at first blush to use the "Field()" constructor for this, but
> > as we see from this thread it is not intuitive, and can confuse by
> > virtue of a new, "special" form of a heretofore clear constructor).
>
> > define_table() has a special first parameter, which is the table name,
> > and an additional parameter which defines "special" table _behavior_,
> > that is "migrate=some_value".
>
> > Probably a better form for this particular change in default behavior
> > would have been something like: id='stiad'
>
> > Having an attribute of table called "id", once you look at the code,
> > shows all the places that the "magic field" (literal) "id" exists,
> > and should be replaced by an attribute (with default of id='id'; but
> > I digress...
>
> > I think, for define_table, a parameter of the form: id='staid'
>
> > would be both easier to explain (changes some default behavior of the
> > table, just as migrate does), more consistent with the historical
> > implementation, and at the same time would give the added benefit of
> > showing up a common, and problematic coding style w/in gluon of using
> > FNMs ("flaming magic numbers" - that is, a repetitive constant value
> > where a symboic value would make the code both more readable, and more
> > maintainable).
>
> > - Yarko
>
> > > ~Brian
>
> > > On Dec 10, 6:50 pm, Tim Michelsen <timmichel...@gmx-topmail.de> wrote:
>
> > > > > You can tell your model the path to the existing sqlite database file
> > > > > with something like
>
> > > > [...]
>
> > > > Thanks a lot for your verbose help! I really appreciate it.
>
> > > > > As for telling it which existing field to use as the ID, as DenesL
> > > > > pointed out if the field isn't already named ID I don't think you can
> > > > > at the moment.
>
> > > > > If you really want to use the station number (t.staid) as your ID, why
> > > > > not just add a new field called ID to your existing table (using
> > > > > sqlite-browser) and then set the value to match t.staid? Something
> > > > > like
>
> > > > I am not a database guru. So I still do not understand why t.staid could
> > > > not be the PK (= ID).
>
> > > > Regards,
> > > > Timmie
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@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.
