It is more than a convenience. What if the user types an unprintable
character in the ISBN? The database would take it but it would be
nearly impossible to get to the record. You can have other unique
fields in web2py, but you must also have the ID.

On Mar 11, 11:08 am, DenesL <denes1...@yahoo.ca> wrote:
> On Mar 11, 9:56 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > Should the record id be assigned by the DB or by the user? I
> > think it should be assigned by the DB. The practical issue is that
> > SQLFORM assumes the current record id. You change that and everything
> > break. It can be fixed but web2py will become much more bloated. I
> > believe having an autoincrement id should be considered good practice
> > and enforced by web2py.
>
> Record id is just a convenience, you can get to a specific record
> using its primary key(s) and that is how most tables are normally
> built.
> So, e.g. the ISBN number can be a primary key in a books DB and there
> is not much difference (unless I am failing to see something) between
> using it or using an extra id field.
> When the primary key consists of several fields the id-ing can be done
> using a list.
> I honestly don't know how much bloating can this produce.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@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
-~----------~----~----~----~------~----~------~--~---

Reply via email to