On Thu, Mar 12, 2009 at 6:32 AM, DenesL <denes1...@yahoo.ca> wrote: > > > > Let's keep at this - for as I read, and have all my reactions (both > > positive, and spotting potential trouble) one thing that is beginning to > > emerge - this has the potential to be very useful. > > Thanks Yarko, forgive my lack of clarity but this is still a Swiss > cheese to me, full of holes (I wish I had Massimo's brain). > As a I said, this need to be refined, a lot, and if the end product > does not bear any resemblance to the original post, that is fine by me > too. > > As you point out, this calls for an external table definition. > > Some snips from http://en.wikipedia.org/wiki/Database_view : > > In database theory, a view consists of a stored query accessible as a > virtual table composed of the result set of a query. Unlike ordinary > tables (base tables) in a relational database, a view does not form > part of the physical schema: it is a dynamic, virtual table computed > or collated from data in the database. Changing the data in a table > alters the data shown in subsequent invocations of the view. > > Just as functions (in programming) can provide abstraction, so > database users can create abstraction by using views. > > Database practitioners can define views as read-only or updatable. If > the database system can determine the reverse mapping from the view > schema to the schema of the underlying base tables, then the view is > updatable. INSERT, UPDATE, and DELETE operations can be performed on > updatable views. Read-only views do not support such operations > because the DBMS cannot map the changes to the underlying base tables. >
Yes - thanks... I think this is what I alredy knew. Of the supported DB's, I know sqlite creates read-only views (which is OK if we think about providing views for the purpose of providing a way to use existing tables which do not have a primary key necessarily named "id", as well as for ways of extending existing tables using web2py. The challenges of this, I think are: - web2py operations should work with web2py view definitions without distinction (they should work "just as" tables); - it would seem if we follow this path - creating SQL View thru DAL, then one necessary constraint is that tables used for crating a view (if there is more than one) MUST be on the same server. Since I don't know that we currently have a way to detect this, then we have a fundamental problem. Perhaps if the db URI were parsed and shown to be the same target (eg. server) but not necessarily the same user (perhaps we are a read-only user on a legacy db, but owner on the extension we will create)... This needs more thought I think... It is interesting, potentially useful, and raises some interesting questions. Massimo - if the "SQL SELECT" is what is stored in a view, how difficult (for the moment ignoring performance) do you think it would be to implement VIEWS in DAL? If we had cross-server views, this really would be something to offer that general DB's could not so easily provide. If we did go down that path, we would definitely need the re-naming idiom handles seemlessly, e.g. SELECT table.primary_key as id or equivalent effect. - Yarko > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
