From 0dff7f4ed286ac108a7784cc7e5d38e805b233bb Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Sun, 10 Dec 2006 17:42:31 +0000 Subject: [PATCH] removing references to 0.2 series from docs upgrade version number to 0.3.2 --- CHANGES | 12 +++++++----- doc/build/content/datamapping.txt | 2 +- doc/build/content/metadata.txt | 2 +- doc/build/content/plugins.txt | 6 +++--- doc/build/content/unitofwork.txt | 2 +- doc/build/genhtml.py | 2 +- setup.py | 2 +- 7 files changed, 15 insertions(+), 13 deletions(-) diff --git a/CHANGES b/CHANGES index af2ca2570c..6a776db7e4 100644 --- a/CHANGES +++ b/CHANGES @@ -11,6 +11,7 @@ back to 0.2.8 levels - various speedups in attributes module - identity map in Session is by default *no longer weak referencing*. to have it be weak referencing, use create_session(weak_identity_map=True) +fixes [ticket:388] - MySQL detects errors 2006 (server has gone away) and 2014 (commands out of sync) and invalidates the connection on which it occured. - MySQL bool type fix: [ticket:307] @@ -20,20 +21,21 @@ to have it be weak referencing, use create_session(weak_identity_map=True) - assign_mapper in assignmapper extension returns the created mapper [changeset:2110] - added label() function to Select class, when scalar=True is used -to create a scalar subquery. +to create a scalar subquery +i.e. "select x, y, (select max(foo) from table) AS foomax from table" - added onupdate and ondelete keyword arguments to ForeignKey; propigate to underlying ForeignKeyConstraint if present. (dont propigate in the other direction, however) - fix to session.update() to preserve "dirty" status of incoming object -- sending a selectable to an IN no longer creates a "union" out of multiple -selects; only one selectable to an IN is allowed now (make a union yourself -if union is needed; explicit better than implicit, dont guess, etc.) +- sending a selectable to an IN via the in_() function no longer creates +a "union" out of multiple selects; only one selectable to a the in_() function +is allowed now (make a union yourself if union is needed) - improved support for disabling save-update cascade via cascade="none" etc. - added "remote_side" argument to relation(), used only with self-referential mappers to force the direction of the parent/child relationship. replaces the usage of the "foreignkey" parameter for "switching" the direction. "foreignkey" argument is deprecated for all uses and will eventually -be replaced by an argument dedicated to ForeignKey specification; +be replaced by an argument dedicated to ForeignKey specification on mappers. 0.3.1 - Engine/Pool: diff --git a/doc/build/content/datamapping.txt b/doc/build/content/datamapping.txt index 108f4b1f03..6b872c36fb 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 be2915e254..b3f7774f8c 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 8229693c18..ae4291e8b4 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 4c9bac8706..b417731580 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 24d400abb5..858d100dfb 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) diff --git a/setup.py b/setup.py index fafc15e0aa..1c9c2bdbf3 100644 --- a/setup.py +++ b/setup.py @@ -3,7 +3,7 @@ use_setuptools() from setuptools import setup, find_packages setup(name = "SQLAlchemy", - version = "0.3.1", + version = "0.3.2", description = "Database Abstraction Library", author = "Mike Bayer", author_email = "mike_mp@zzzcomputing.com", -- 2.47.2