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 believe the current implementation is much cleaner than the one you
propose, in fact it was implemented without creating any new API.
Unfortunately these features are only one month old therefore they are
not in the book, need more testing and need more documentation. 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 (?!). In fact the 'id' type always existed. The 'id'
field has always been of 'id' type since web2py 1.0 in October 2007.
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.
