Am 29.05.2013 21:29, schrieb Ed Leafe:
On May 22, 2013, at 7:28 AM, Sibylle
Koczian<[email protected]> wrote:
File "/home/sib/src/dabo-master/dabo/biz/dBizobj.py", line 300, in
__init__ apply(secondary.__init__, (self,) + args, kwargs)
TypeError: __init__() takes exactly 3 arguments (2 given)
What is happening here? What is "secondary" and what is its
__init__ method?
'secondary' is the cursor class for the particular backend; in your
case, Firebird. Apparently the Firebird cursor requires more than the
standard arguments. Can you look at the kinterbasdb and/or fdb code
to see what arguments are required for the cursor class's __init__()
method?
I didn't find that code in the kinterbasdb package - could it be
contained in _kinterbasdb.so?
FDB: The arguments seem to be "connection" and "transaction" (and self,
of course). Could the "transaction" parameter be new?
class Cursor(object):
"""Represents a database cursor, which is used to execute SQL
statement and
manage the context of a fetch operation.
.. important::
DO NOT create instances of this class directly! Use only
:meth:`Connection.cursor`, :meth:`Transaction.cursor` and
:meth:`ConnectionGroup.cursor` to get Cursor instances that
operate in
desired context.
.. note::
Cursor is actually a high-level wrapper around
:class:`PreparedStatement`
instance(s) that handle the actual SQL statement execution and
result
management. Cursor has an internal cache of PreparedStatements,
so when
the same SQL statement is executed repeatedly, related
PreparedStatement
is re-used, which enhances performance. This convenient
enhancement has
a side effect: Cursor that was used to perform many different
SQL statements
may hold very large cache of PerapedStatements. To clear the
cache, you'll
need to call :meth:`clear_cache`.
.. tip::
Cursor supports the iterator protocol, yielding tuples of values
like
:meth:`fetchone`.
"""
#: (Read/Write) As required by the Python DB API 2.0 spec, the
value of this
#: attribute is observed with respect to the :meth:`fetchmany`
method. However,
#: changing the value of this attribute does not make any
difference in fetch
#: efficiency because the database engine only supports fetching a
single row
#: at a time.
arraysize = 1
def __init__(self, connection, transaction):
"""
.. important::
The association between a Cursor and its
:class:`Transaction` and
:class:`Connection` is set when the Cursor is created, and
cannot be
changed during the lifetime of that Cursor.
:param connection: :class:`Connection` instance this cursor
should be bound to.
:param transaction: :class:`Transaction` instance this cursor
should be bound to.
"""
self._prepared_statements = {}
self._connection = connection
self._transaction = transaction
self._ps = None # current prepared statement
Possibly this might be helpful (from the FDB documentation):
Distributed transactions
Support for Distributed Transactions works in slightly differently than
in KDB. FDB uses ConnectionGroup class like KDB with the same interface,
but DT is not bound to main transaction of individual connections
managed by group. That means that Cursor instances obtained from
Connection don’t work in DT if connection is part of ConnectionGroup,
but work normally in connection context. To get Cursor for specific
connection that works in DT, use fdb.ConnectionGroup.cursor() method and
pass the connection as parameter. We believe that this arrangement is
more logical and flexible than KDB’s way.
Transaction context for cursor objects depends on how cursor is
obtained/created:
fdb.Connection.cursor() - Works in context of “main” transaction
for connection.
fdb.Transaction.cursor() - Works in context of this transaction.
fdb.ConnectionGroup.cursor() - Works in context of Distributed
Transaction
Thank you,
Sibylle
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
