Fms Param V2.0

[Yoshi Heffernan]

ThisAPI has been defined to encourage similarity between the Pythonmodules that are used to access databases. By doing this, we hope toachieve a consistency leading to more easily understood modules, codethat is generally more portable across databases, and a broader reachof database connectivity from Python.

This document describes the Python Database API Specification 2.0 anda set of common optional extensions. The previous version 1.0 versionis still available as reference, in PEP 248. Package writers areencouraged to use this version of the specification as basis for newinterfaces.

Sharing in the above context means that two threads may use aresource without wrapping it using a mutex semaphore to implementresource locking. Note that you cannot always make externalresources thread safe by managing access using a mutex: theresource may rely on global variables or other external sourcesthat are beyond your control.

The connection will be unusable from this point forward; an Error(or subclass) exception will be raised if any operation isattempted with the connection. The same applies to all cursorobjects trying to use the connection. Note that closing aconnection without committing the changes first will cause animplicit rollback to be performed.

In case a database does provide transactions this method causes thedatabase to roll back to the start of any pending transaction. Closing aconnection without committing the changes first will cause an implicitrollback to be performed.

Call a stored database procedure with the given name. The sequenceof parameters must contain one entry for each argument that theprocedure expects. The result of the call is returned as modifiedcopy of the input sequence. Input parameters are left untouched,output and input/output parameters replaced with possibly newvalues.

A reference to the operation will be retained by the cursor. Ifthe same operation object is passed in again, then the cursor canoptimize its behavior. This is most effective for algorithmswhere the same operation is used, but different parameters arebound to it (many times).

For maximum efficiency when reusing an operation, it is best touse the .setinputsizes() method to specify the parameter typesand sizes ahead of time. It is legal for a parameter to not matchthe predefined information; the implementation should compensate,possibly with a loss of efficiency.

Use of this method for an operation which produces one or moreresult sets constitutes undefined behavior, and the implementationis permitted (but not required) to raise an exception when itdetects that a result set has been created by an invocation of theoperation.

Note there are performance considerations involved with the sizeparameter. For optimal performance, it is usually best to use the.arraysize attribute. If the size parameter is used, then itis best for it to retain the same value from one .fetchmany()call to the next.

Implementations must observe this value with respect to the.fetchmany() method, but are free to interact with the databasea single row at a time. It may also be used in the implementationof .executemany().

To overcome this problem, a module must provide the constructorsdefined below to create objects that can hold special values. Whenpassed to the cursor methods, the module can then detect the propertype of the input parameter and bind it accordingly.

During the lifetime of DB API 2.0, module authors have often extendedtheir implementations beyond what is required by this DB APIspecification. To enhance compatibility and to provide a clean upgradepath to possible future versions of the specification, this sectiondefines a set of common extensions to the core DB API 2.0specification.

As with all DB API optional features, the database module authors arefree to not implement these additional attributes and methods (usingthem will then result in an AttributeError) or to raise aNotSupportedError in case the availability can only be checked atrun-time.

It has been proposed to make usage of these extensions optionallyvisible to the programmer by issuing Python warnings through thePython warning framework. To make this feature useful, the warningmessages must be standardized in order to be able to mask them. Thesestandard messages are referred to below as Warning Message.

This method should use native scrollable cursors, if available,or revert to an emulation for forward-only scrollablecursors. The method may raise NotSupportedError to signalthat a specific operation is not supported by the database(e.g. backward scrolling).

The list is cleared by all standard cursor methods calls (prior toexecuting the call) except for the .fetch*() callsautomatically to avoid excessive memory usage and can also becleared by executing del cursor.messages[:].

Changing the setting from True to False (disablingautocommit) will have the database leave autocommit mode and starta new transaction. Changing from False to True (enablingautocommit) has database dependent semantics with respect to howpending transactions are handled. [12]

Deprecation notice: Even though several database modules implementboth the read and write nature of this attribute, setting theautocommit mode by writing to the attribute is deprecated, sincethis may result in I/O and related exceptions, making it difficultto implement in an async context. [13]

The core DB API specification only introduces a set of exceptionswhich can be raised to report errors to the user. In some cases,exceptions may be too disruptive for the flow of a program or evenrender execution impossible.

For these cases and in order to simplify error handling when dealingwith databases, database module authors may choose to implement userdefinable error handlers. This section describes a standard way ofdefining these error handlers.

where connection is a reference to the connection on which thecursor operates, cursor a reference to the cursor (or None incase the error does not apply to a cursor), errorclass is anerror class which to instantiate using errorvalue asconstruction argument.

The standard error handler should add the error information to theappropriate .messages attribute (Connection.messages orCursor.messages) and raise the exception defined by the givenerrorclass and errorvalue parameters.

If a database backend provides support for two-phase commit and thedatabase module author wishes to expose this support, the followingAPI should be implemented. NotSupportedError should be raised, if thedatabase backend support for two-phase commit can only be checked atrun-time.

The type of the object returned by .xid() is not defined, butit must provide sequence behaviour, allowing access to the threecomponents. A conforming database module could choose torepresent transaction IDs with tuples rather than a custom object.

When called with a transaction ID xid, the database commits thegiven transaction. If an invalid transaction ID is provided, aProgrammingError will be raised. This form should be calledoutside of a transaction, and is intended for use in recovery.

When called with a transaction ID xid, it rolls back the giventransaction. If an invalid transaction ID is provided, aProgrammingError is raised. This form should be called outsideof a transaction, and is intended for use in recovery.

There are several existing tools available which provide helpers forthis task. Most of them use the approach of using the column namesdefined in the cursor attribute .description as basis for the keysin the row dictionary.

The Python Database API 2.0 introduces a few major changes compared tothe 1.0 version. Because some of these changes will cause existing DBAPI 1.0 based scripts to break, the major version number was adjustedto reflect this change.

The preferred approach is to not implement the method and thus havePython generate an AttributeError in case the method isrequested. This allows the programmer to check for databasecapabilities using the standard hasattr() function.

For some dynamically configured interfaces it may not beappropriate to require dynamically making the methodavailable. These interfaces should then raise aNotSupportedError to indicate the non-ability to perform theroll back when the method is invoked.

This minor release contains bug fixes for reactive expressions and a few minor documentation improvements. Thanks to @jrycw for their first contribution! And to @ahuang11, @maximelt, and @philippjfr for their continued maintenance and development efforts.

This minor release focuses on improving reactive expressions and support for asynchronous (and synchronous) generators. Many thanks to @maximelt, @Hoxbro and @philippjfr for their continued maintenance and development efforts.

This patch release fixes a few bugs and introduces a performance enhancement. Many thanks to @alfredocarella for their first contribution, and to the maintainers @maximlt and @philippjfr for contributing to this release.

This minor release fixes a number of bugs, including a regression introduced by the replacement of the build backend (setuptools for hatchling) which led to the doc folder being wrongly packaged. Many thanks to @SultanOrazbayev for their first contribution, to @musicinmybrain for spotting the regression and submitting fixes, and to the maintainers @Hoxbro, @jbednar and @maximlt for contributing to this release.

Param 2.0 is a major new release available for Python 3.8 and above, significantly streamlining, simplifying, and improving the Param API. Many long-supported but also long-obsolete functions, methods, and usages will now warn loudly so that you can make sure your code is only using the fully supported and safe current approaches. Because upgrading to Param 2 is likely to reveal compatibility issues with older codebases, new releases in the 1.x series are expected to continue for some time, focused on compatibility with the ecosystem rather than adding new features. Thus you can keep using Param 1.x with your older code, but Param 2 is the future!

The objects slot of a Selector was previously highly confusing, because it accepted either a dictionary or a list for initialization but then was accessible only as a list, making it difficult to watch or update the objects. There is now a ListProxy wrapper around Selector.objects (with forward and backward compatibility) to easily update objects and watch objects updates (#598, #825)

3a8082e126