> Yes - thanks... I think this is what I alredy knew.
The snips from wikipedia highlite:
1) a view consists of a stored query (hence the sqlset in my first
stab, but I might be wrong).
2) INSERT, UPDATE and DELETE are possible with views under certain
conditions, so lets not restrict their use.
> I know sqlite creates read-only views (which is OK if we think about
sqlite is not a production level db, let see instead what the others
support
> 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.
tables MUST be in the same db, let alone server, e.g. you can not do:
dbX.define_table('dog',SQLField('name'),SQLField('owner',dbY.person))
but this restriction can be worked on independently of views;
this also seems to suggest a need for a dictionary of DBs.
> 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.
add cross-db to that
>
> 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
-~----------~----~----~----~------~----~------~--~---
