On Dec 11, 10:13 am, mdipierro <[email protected]> wrote:
> 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)
... and this is what I meant when I said there is something special
about 'id' - it is not like other fields, e.g. "special";
maybe this is ok - but there is evidence in this thread of confusion
(and, yes, I am aware it is new...)
>
> - 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).
... I am not familiar w/ Denes's extension (and was not commenting on
it; but thanks for pointing it out, that it is different).
>
> Massimo
>
> On Dec 11, 10:03 am, Yarko Tymciurak <[email protected]>
> wrote:
>
>
>
> > On Dec 11, 12:41 am, Brian M <[email protected]> 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 <[email protected]> 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 [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.