On Apr 1, 9:20 pm, Yarko Tymciurak wrote:
> > http://www.postgresql.org/docs/8.3/interactive/sql-createrule.html
>
> and looking at this, it seems fairly straight forward:
Yes it does. The manual threw me when it said that "*Currently* views
are read only" but that "you can get the *effect* of a
usual DB API cursor methods
(execute, fetchone, fetchall, etc.). That's all the flexibility I've
ever had plus the SQLDB() handles the connection pooling for me.
--David
On Apr 1, 5:36 pm, Yarko Tymciurak wrote:
> On Wed, Apr 1, 2009 at 3:22 PM, David Niergarth wrote:
>
> > But
But how would you handle updates (views being read-only).
--David
On Apr 1, 2:34 pm, Yarko Tymciurak wrote:
> On Wed, Apr 1, 2009 at 12:34 AM, mdipierro wrote:
>
> > Can you create a custom database view and map the field?
>
> Yes - this is the way to do it in your db server. You also want to
fferently than the other database backends.
>
> On Apr 1, 7:22 am, David Niergarth wrote:
>
> > > Is it really backward compatible? Have you tried?
>
> > I tried basic integer indexing and slicing, which work as expected, as
> > does the dictionary interface. I jus
> something smarter if there is)
> so all schema tables would be gathered in one schema with many views... just
> an idea?
>
> Boris
>
>
>
> On Wed, Apr 1, 2009 at 6:24 AM, David Niergarth wrote:
>
> > I wondered if that might be the case. db._cursor will do jus
> Is it really backward compatible? Have you tried?
I tried basic integer indexing and slicing, which work as expected, as
does the dictionary interface. I just went through all the scenarios I
could think of and found two differences with DictCursor.
1) Extended slicing fails with an except
One postgres-specific change we made to our copy of gluon.sql to make
things a bit easier was to add the import
import psycopg2.extras
and change the line
self._pool_connection(lambda : psycopg2.connect(msg))
to
self._pool_connection(lambda :
psycopg2.extras.DictConn
om names where id=%(id)s;",
> {'id': id})
> db._cursor.fetchall()
>
> On Mar 31, 10:54 pm, David Niergarth wrote:
>
> > For our application we are not using the ORM features of the DAL (see
> > P.S. explanation). All of our non-auth queries use db.execute
For our application we are not using the ORM features of the DAL (see
P.S. explanation). All of our non-auth queries use db.executesql(sql).
It seems like executesql() should support the optional mapping-or-
tuple argument that the underlying DB API 2.0 cursor supports. For
example,
cursor.ex
Hello,
I was at the PyCon dojo and got to meet several of you afterward. The
dojo project is a very good example for showing the breadth of web2py.
I heard a couple of people say "How come nobody knows about web2py
yet?" afterward. You may want to consider putting the dojo example on
the web2py d
Hello,
I was at the PyCon dojo and got to meet several of you afterward. The
dojo project is a very good example for showing the breadth of web2py.
I heard a couple of people say "How come nobody knows about web2py
yet?" afterward. You may want to consider putting the dojo example on
the web2py d
11 matches
Mail list logo
