I reviewed it! There is nothing special in Field(...,'id').
All tables must have a field of type 'id' with two exceptions:
- if you do not specify one, one is created automatically and called
'id' as the type (Field('id','id'), the default)
- legacy database can have more complex keys (Denes' keyed tables) and
they do not need an 'id' field (so far works only for mssql and ingres
I think).
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.
