Can someone please explain how the default primary key can survive data
refreshes over the long term?
My instinct is to create a natural primary key for all tables, e.g.,
scoreID (A, B, C, D), instead of using the default primary auto-increment
field.
db.define_table('ScoreLookupTable', ## validation table for rating anything
Field('*scoreID*','string'), ## e.g., "A", "B", "C". This is my choice for
natural primary key
Field('scoreDescription','string')) ## A - highest approval, B - approve, C
- lukewarm endorsement.., D.. F - strongly disapprove
scoreID can survive data refreshes and long term project makeovers forever.
"A" will always stay "A", and "B" will always stay "B".
if I rely on the default primary key, ScoreLookupTable.id, which is an
auto-increment integer, I'm concerned that web2py will change the integers
when data is reloaded into the table. For example, let's say I take the
app to a new host, and reload the data. Will web2py keep the "id" field
values, or overwrite them? In this case, I want it to pick up
auto-incrementing from where it left off. Does it know to do that? How
stable is the data persistence This project will be updated and
re-written many times and I want the primary key to persist as the app is
highly dependent on relations.
thanks,
Alex Glaros
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
