diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/build/content/datamapping.txt | 2 | ||||
| -rw-r--r-- | doc/build/content/metadata.txt | 2 | ||||
| -rw-r--r-- | doc/build/content/plugins.txt | 6 | ||||
| -rw-r--r-- | doc/build/content/unitofwork.txt | 2 | ||||
| -rw-r--r-- | doc/build/genhtml.py | 2 |
5 files changed, 7 insertions, 7 deletions
diff --git a/doc/build/content/datamapping.txt b/doc/build/content/datamapping.txt index 108f4b1f0..6b872c36f 100644 --- a/doc/build/content/datamapping.txt +++ b/doc/build/content/datamapping.txt @@ -12,7 +12,7 @@ The `Mapper`'s role is to perform SQL operations upon the database, associating When a `Mapper` is created to associate a `Table` object with a class, all of the columns defined in the `Table` object are associated with the class via property accessors, which add overriding functionality to the normal process of setting and getting object attributes. These property accessors keep track of changes to object attributes; these changes will be stored to the database when the application "flushes" the current state of objects (known as a *Unit of Work*). -Two objects provide the primary interface for interacting with Mappers and the "unit of work" in SA 0.2, which are the `Query` object and the `Session` object. `Query` deals with selecting objects from the database, whereas `Session` provides a context for loaded objects and the ability to communicate changes on those objects back to the database. +Two objects provide the primary interface for interacting with Mappers and the "unit of work", which are the `Query` object and the `Session` object. `Query` deals with selecting objects from the database, whereas `Session` provides a context for loaded objects and the ability to communicate changes on those objects back to the database. The primary method on `Query` for loading objects is its `select()` method, which has similar arguments to a `sqlalchemy.sql.Select` object. But this select method executes automatically and returns results, instead of awaiting an execute() call. Instead of returning a cursor-like object, it returns an array of objects. diff --git a/doc/build/content/metadata.txt b/doc/build/content/metadata.txt index be2915e25..b3f7774f8 100644 --- a/doc/build/content/metadata.txt +++ b/doc/build/content/metadata.txt @@ -238,7 +238,7 @@ Within the `MetaData` collection, this table will be identified by the combinati Feature Status: [Alpha Implementation][alpha_implementation] -Many table, schema, or column names require quoting to be enabled. Reasons for this include names that are the same as a database reserved word, or for identifiers that use MixedCase, where the database would normally "fold" the case convention into lower or uppercase (such as Postgres). SQLAlchemy as of version 0.2.8 will attempt to automatically determine when quoting should be used. It will determine a value for every identifier name called `case_sensitive`, which defaults to `False` if the identifer name uses no uppercase letters, or `True` otherwise. This flag may be explicitly set on any schema item as well (schema items include `Table`, `Column`, `MetaData`, `Sequence`, etc.) to override this default setting, where objects will inherit the setting from an enclosing object if not explicitly overridden. +Many table, schema, or column names require quoting to be enabled. Reasons for this include names that are the same as a database reserved word, or for identifiers that use MixedCase, where the database would normally "fold" the case convention into lower or uppercase (such as Postgres). SQLAlchemy will attempt to automatically determine when quoting should be used. It will determine a value for every identifier name called `case_sensitive`, which defaults to `False` if the identifer name uses no uppercase letters, or `True` otherwise. This flag may be explicitly set on any schema item as well (schema items include `Table`, `Column`, `MetaData`, `Sequence`, etc.) to override this default setting, where objects will inherit the setting from an enclosing object if not explicitly overridden. When `case_sensitive` is `True`, the dialect will do what it has to in order for the database to recognize the casing. For Postgres and Oracle, this means using quoted identifiers. diff --git a/doc/build/content/plugins.txt b/doc/build/content/plugins.txt index 8229693c1..ae4291e8b 100644 --- a/doc/build/content/plugins.txt +++ b/doc/build/content/plugins.txt @@ -7,7 +7,7 @@ SQLAlchemy has a variety of extensions and "mods" available which provide extra **Author:** Daniel Miller -This plugin is used to instantiate and manage Session objects. As of SQLAlchemy 0.2 it is the preferred way to provide thread-local session functionality to an application. It provides several services: +This plugin is used to instantiate and manage Session objects. It is the preferred way to provide thread-local session functionality to an application. It provides several services: * serves as a factory to create sessions of a particular configuration. This factory may either call `create_session()` with a particular set of arguments, or instantiate a different implementation of `Session` if one is available. * for the `Session` objects it creates, provides the ability to maintain a single `Session` per distinct application thread. The `Session` returned by a `SessionContext` is called the *contextual session.* Providing at least a thread-local context to sessions is important because the `Session` object is not threadsafe, and is intended to be used with localized sets of data, as opposed to a single session being used application wide. @@ -211,7 +211,7 @@ Configuration of SelectResults may be per-Query, per Mapper, or per application: # globally configure all Mappers to return SelectResults, using the "selectresults" mod import sqlalchemy.mods.selectresults -SelectResults greatly enhances querying and is highly recommended. For example, heres an example of constructing a query using a combination of joins and outerjoins (requires 0.2.9 or above): +SelectResults greatly enhances querying and is highly recommended. For example, heres an example of constructing a query using a combination of joins and outerjoins: {python} mapper(User, users_table, properties={ @@ -371,7 +371,7 @@ For the common case where the association object's creation needs to be specifie **Author:** Mike Bayer and Daniel Miller -`threadlocal` is an extension that was created primarily to provide backwards compatibility with the SQLAlchemy 0.1 series. It uses three features which SQLAlchemy 0.2 and above provide as distinct features: `SessionContext`, `assign_mapper`, and the `TLEngine`, which is the `Engine` used with the threadlocal `create_engine()` strategy. It is **strongly** recommended that these three features are understood individually before using threadlocal. +`threadlocal` is an extension that was created primarily to provide backwards compatibility with the older SQLAlchemy 0.1 series. It uses three features which SQLAlchemy 0.2 and above provide as distinct features: `SessionContext`, `assign_mapper`, and the `TLEngine`, which is the `Engine` used with the threadlocal `create_engine()` strategy. It is **strongly** recommended that these three features are understood individually before using threadlocal. In SQLAlchemy 0.1, users never dealt with explcit connections and didn't have a very explicit `Session` interface, instead relying upon a more magical global object called `objectstore`. The `objectstore` idea was wildly popular with about half of SA's users, and completely unpopular with the other half. The threadlocal mod basically brings back `objectstore`, which is in fact just a `SessionContext` where you can call `Session` methods directly off of it, instead of saying `context.current`. For `threadlocal` to faithfully produce 0.1 behavior, it is invoked as a *mod* which globally installs the objectstore's mapper extension, such that all `Mapper`s will automatically assign all new instances of mapped classes to the objectstore's contextual `Session`. Additionally, it also changes the default engine strategy used by `create_engine` to be the "threadlocal" strategy, which in normal practice does not affect much. diff --git a/doc/build/content/unitofwork.txt b/doc/build/content/unitofwork.txt index 4c9bac870..b41773158 100644 --- a/doc/build/content/unitofwork.txt +++ b/doc/build/content/unitofwork.txt @@ -16,7 +16,7 @@ SQLAlchemy's unit of work includes these functions: * an Identity Map, which is a dictionary storing the one and only instance of an object for a particular table/primary key combination. This allows many parts of an application to get a handle to a particular object without any chance of modifications going to two different places. * The sole interface to the unit of work is provided via the `Session` object. Transactional capability, which rides on top of the transactions provided by `Engine` objects, is provided by the `SessionTransaction` object. * Thread-locally scoped Session behavior is available as an option, which allows new objects to be automatically added to the Session corresponding to by the *default Session context*. Without a default Session context, an application must explicitly create a Session manually as well as add new objects to it. The default Session context, disabled by default, can also be plugged in with other user-defined schemes, which may also take into account the specific class being dealt with for a particular operation. -* The Session object in SQLAlchemy 0.2 borrows conceptually from that of [Hibernate](http://www.hibernate.org), a leading ORM for Java that was a great influence on the creation of the [JSR-220](http://jcp.org/aboutJava/communityprocess/pfd/jsr220/index.html) specification. SQLAlchemy, under no obligation to conform to EJB specifications, is in general very different from Hibernate, providing a different paradigm for producing queries, a SQL API that is useable independently of the ORM, and of course Pythonic configuration as opposed to XML; however, JSR-220/Hibernate makes some pretty good suggestions with regards to the mechanisms of persistence. +* The Session object borrows conceptually from that of [Hibernate](http://www.hibernate.org), a leading ORM for Java that was a great influence on the creation of the [JSR-220](http://jcp.org/aboutJava/communityprocess/pfd/jsr220/index.html) specification. SQLAlchemy, under no obligation to conform to EJB specifications, is in general very different from Hibernate, providing a different paradigm for producing queries, a SQL API that is useable independently of the ORM, and of course Pythonic configuration as opposed to XML; however, JSR-220/Hibernate makes some pretty good suggestions with regards to the mechanisms of persistence. ### Object States {@name=states} diff --git a/doc/build/genhtml.py b/doc/build/genhtml.py index 24d400abb..858d100df 100644 --- a/doc/build/genhtml.py +++ b/doc/build/genhtml.py @@ -24,7 +24,7 @@ files = [ ] title='SQLAlchemy 0.3 Documentation' -version = '0.3.1' +version = '0.3.2' root = toc.TOCElement('', 'root', '', version=version, doctitle=title) |