It should not be too difficult to support this in web2py
What about the syntax:
db.define_view('myview',db.Field('col1'),db.Field('col2'),select=db
(...)._select(....))
and access it as a table db.myview as a normal table.
A view would be a special table that does not have an "id" field and
does not support insert.
Comments? Suggestions?
Massimo
On Mar 11, 4:20 pm, Yarko Tymciurak <[email protected]> wrote:
> A view is kind of a special SQL select statement - so maybe this THIS could
> be included as part of the DAL... that would actually be the right way to
> let people easily map from web2py (I don't know why I didn't think of that
> before).
> You can make a aview be a temporary table (I don't know what the performance
> implications for the various dbs are for temporary vs. persistent view - I
> know is some cases a view is basically an SQL select statement that runs at
> each access).
>
> so something like SELECT foo as bar from MY_TABLE is the general
> idea...
>
> View syntax (some examples):
>
> http://www.postgresql.org/docs/8.2/interactive/sql-createview.html
>
> http://dev.mysql.com/doc/refman/5.0/en/create-view.htmlhttp://dev.mysql.com/doc/refman/5.0/en/view-syntax.html
>
> http://www.sql-server-performance.com/articles/dba/view_basics_p1.aspx
>
> http://www.sqlite.org/lang_createview.htmlhttp://www.sqlite.org/omitted.html
>
> http://www.dba-oracle.com/concepts/views.htm
>
> http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topi...
>
> Did I miss any?
>
> Regards,
> Yarko
>
> On Wed, Mar 11, 2009 at 3:54 PM, mdipierro <[email protected]> wrote:
>
> > Can you point us to an example of how to make a view?
>
> > On Mar 11, 3:48 pm, Yarko Tymciurak <[email protected]> wrote:
> > > 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 <[email protected]>
> > 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 <[email protected]> wrote:
> > > > > On Mar 11, 9:56 am, mdipierro <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
