in essence, web2py imposes a standard, consistent primary key for all web2py tables... This is not bad.
I still argue (and the more I think of it, the more strongly) that this mapping for operating w/ legacy, existing databases should NOT be handled by web2py --- rather, the DB is the place to handle this. Make a VIEW in your DB. It's a db / connection specific issue by definition (so that strongly suggests it does NOT belong in web2py); It's something any DB can handle already (no need to re-invent an existing wheel); In sqllite (probably mostly an issue if you're working on an embedded system), the view is READ ONLY, and even this is not a bad thing. There are ways around it in sqlite; The more I hear this discussion (and it has been - in one way or another - going on for maybe a year...) the more two things settle for me: - I REALLY like the idea of mapping existing databases so that you can interface them with web2py; - I REALLY think this mapping belongs in the DB --- NOT in web2py code. Yarko On Wed, Mar 11, 2009 at 11:15 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
