Mike Bayer [Tue, 8 Jan 2013 15:04:55 +0000 (10:04 -0500)]
Tweaked the "REQUIRED" symbol used by the compiler to identify
INSERT/UPDATE bound parameters that need to be passed, so that
it's more easily identifiable when writing custom bind-handling
code. [ticket:2648]
Mike Bayer [Wed, 2 Jan 2013 16:37:20 +0000 (11:37 -0500)]
- remove the test against bindparam('x') for the bind/result SQL expressions
- apply a consistent approach to the "see if method X is implemented" conditionals
Mike Bayer [Wed, 2 Jan 2013 16:26:37 +0000 (11:26 -0500)]
Fixed bug in :func:`.postgresql.array` construct whereby using it
inside of an :func:`.expression.insert` construct would produce an
error regarding a parameter issue in the ``self_group()`` method.
Mike Bayer [Sun, 30 Dec 2012 00:31:28 +0000 (19:31 -0500)]
Extended the :doc:`/core/inspection` system so that all Python descriptors
associated with the ORM or its extensions can be retrieved.
This fulfills the common request of being able to inspect
all :class:`.QueryableAttribute` descriptors in addition to
extension types such as :class:`.hybrid_property` and
:class:`.AssociationProxy`. See :attr:`.Mapper.all_orm_descriptors`.
Mike Bayer [Sat, 22 Dec 2012 23:40:06 +0000 (18:40 -0500)]
- add tests to ensure SELECT of dynamic collection not emitted
on regular append/remove history
- fix the real cause of the original #2637 issue, backrefs call upon
the "pop()" method now which wasn't implemented for Dynamic
Mike Bayer [Sat, 22 Dec 2012 15:36:55 +0000 (10:36 -0500)]
- revert the full iteration of the collection for a passive history event; that's
the wrong behavior, and for the original #2637 issue we will have to fix the
association proxy, which is #2642
Mike Bayer [Fri, 21 Dec 2012 22:53:57 +0000 (17:53 -0500)]
- significantly rework the approach to collection events and history within DynamicAttributeImpl
- Fixes to the "dynamic" loader on :func:`.relationship`, includes
that backrefs will work properly even when autoflush is disabled,
history events are more accurate in scenarios where multiple add/remove
of the same object occurs, as can often be the case in conjunction
with the association proxy. [ticket:2637]
Mike Bayer [Fri, 14 Dec 2012 15:29:46 +0000 (10:29 -0500)]
More adjustment to this SQLite related issue which was released in
0.7.9, to intercept legacy SQLite quoting characters when reflecting
foreign keys. In addition to intercepting double quotes, other
quoting characters such as brackets, backticks, and single quotes
are now also intercepted. [ticket:2568]
Mike Bayer [Thu, 13 Dec 2012 23:45:15 +0000 (18:45 -0500)]
The :meth:`.Query.select_from` method can now be used with a
:func:`.aliased` construct without it interfering with the entities
being selected. [ticket:2635]
Mike Bayer [Tue, 11 Dec 2012 21:31:41 +0000 (16:31 -0500)]
Fixed a regression caused by :ticket:`2410` whereby a
:class:`.CheckConstraint` would apply itself back to the
original table during a :meth:`.Table.tometadata` operation, as
it would parse the SQL expression for a parent table. The
operation now copies the given expression to correspond to the
new table.
[ticket:2633]
Mike Bayer [Sun, 9 Dec 2012 23:28:08 +0000 (18:28 -0500)]
Fixed table reflection for Oracle when accessing a synonym that refers
to a DBLINK remote database; while the syntax has been present in the
Oracle dialect for some time, up until now it has never been tested.
The syntax has been tested against a sample database linking to itself,
however there's still some uncertainty as to what should be used for the
"owner" when querying the remote database for table information.
Currently, the value of "username" from user_db_links is used to
match the "owner". [ticket:2619]
Mike Bayer [Sun, 9 Dec 2012 01:28:43 +0000 (20:28 -0500)]
Fixed bug where using server_onupdate=<FetchedValue|DefaultClause>
without passing the "for_update=True" flag would apply the default
object to the server_default, blowing away whatever was there.
The explicit for_update=True argument shouldn't be needed with this usage
(especially since the documentation shows an example without it being
used) so it is now arranged internally using a copy of the given default
object, if the flag isn't set to what corresponds to that argument.
Also in 0.7.10. [ticket:2631]
Mike Bayer [Sun, 9 Dec 2012 00:25:04 +0000 (19:25 -0500)]
Fixed bug whereby using a label_length on dialect that was smaller
than the size of actual column identifiers would fail to render
the columns correctly in a SELECT statement.
[ticket:2610]
Mike Bayer [Sat, 8 Dec 2012 21:17:20 +0000 (16:17 -0500)]
internally at least refer to multirow as "multivalues", to distinguish between
an INSERT that's used in executemany() as opposed to one which has a VALUES
clause with multiple entries.
Mike Bayer [Sat, 8 Dec 2012 19:25:42 +0000 (14:25 -0500)]
- multivalued inserts, [ticket:2623]
- update "not supported" messages for empty inserts, mutlivalue inserts
- rework the ValuesBase approach for multiple value sets so that stmt.parameters
does store a list for multiple values; the _has_multiple_parameters flag now indicates
which of the two modes the statement is within. it now raises exceptions if a subsequent
call to values() attempts to call a ValuesBase with one mode in the style of the other
mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode,
and also if a multiple value is passed simultaneously with a kwargs set.
Added tests for these error conditions
- Calling values() multiple times in multivalue mode now extends the parameter list to
include the new parameter sets.
- add error/test if multiple *args were passed to ValuesBase.values()
- rework the compiler approach for multivalue inserts, back to where
_get_colparams() returns the same list of (column, value) as before, thereby
maintaining the identical number of append() and other calls when multivalue
is not enabled. In the case of multivalue, it makes a last-minute switch to return
a list of lists instead of the single list. As it constructs the additional lists, the inline
defaults and other calculated default parameters of the first parameter
set are copied into the newly generated lists so that these features continue
to function for a multivalue insert. Multivalue inserts now add no additional
function calls to the compilation for regular insert constructs.
- parameter lists for multivalue inserts now includes an integer index for all
parameter sets.
- add detailed documentation for ValuesBase.values(), including careful wording
to describe the difference between multiple values and an executemany() call.
- add a test for multivalue insert + returning - it works !
- remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
Mike Bayer [Fri, 7 Dec 2012 00:30:49 +0000 (19:30 -0500)]
The Oracle LONG type, while an unbounded text type, does not appear
to use the cx_Oracle.LOB type when result rows are returned,
so the dialect has been repaired to exclude LONG from
having cx_Oracle.LOB filtering applied. Also in 0.7.10.
[ticket:2620]
Mike Bayer [Fri, 7 Dec 2012 00:10:06 +0000 (19:10 -0500)]
Repaired the usage of ``.prepare()`` in conjunction with
cx_Oracle so that a return value of ``False`` will result
in no call to ``connection.commit()``, hence avoiding
"no transaction" errors. Two-phase transactions have
now been shown to work in a rudimental fashion with
SQLAlchemy and cx_oracle, however are subject to caveats
observed with the driver; check the documentation
for details. Also in 0.7.10.
[ticket:2611]
Idan Kamara [Wed, 5 Dec 2012 22:11:52 +0000 (00:11 +0200)]
compiler: add support for multirow inserts
Some databases support this syntax for inserts:
INSERT INTO table (id, name) VALUES
('v1', 'v2'),
('v3', 'v4');
which greatly increases INSERT speed.
It is now possible to pass a list of lists/tuples/dictionaries as
the values param to the Insert construct. We convert it to a flat
dictionary so we can continue using bind params. The above query
will be converted to:
INSERT INTO table (id, name) VALUES
(:id, :name),
(:id0, :name0);
Currently only supported on postgresql, mysql and sqlite.
Mike Bayer [Tue, 4 Dec 2012 00:49:42 +0000 (19:49 -0500)]
The :class:`.MutableComposite` type did not allow for the
:meth:`.MutableBase.coerce` method to be used, even though
the code seemed to indicate this intent, so this now works
and a brief example is added. As a side-effect,
the mechanics of this event handler have been changed so that
new :class:`.MutableComposite` types no longer add per-type
global event handlers. Also in 0.7.10
Mike Bayer [Sun, 2 Dec 2012 17:37:52 +0000 (12:37 -0500)]
- BinaryExpression now keeps track of "left" and "right" as passed in,
so that they can be compared in ``__nonzero__`` prior to their
self_group() step. [ticket:2621]
Mike Bayer [Sun, 2 Dec 2012 01:12:23 +0000 (20:12 -0500)]
- refactor of pathing mechanics, to address #2614, #2617
- paths now store Mapper + MapperProperty now instead of string key,
so that the parent mapper for the property is known, supports same-named
properties on multiple subclasses
- the Mapper within the path is now always relevant to the property
to the right of it. PathRegistry does the translation now, instead
of having all the outside users of PathRegistry worry about it,
to produce a path that is much more consistent. Paths are now
consistent with mappings in all cases. Special logic to get at
"with_polymorphic" structures and such added also.
- AliasedClass now has two modes, "use_mapper_path" and regular;
"use_mapper_path" is for all those situations where we put an AliasedClass
in for a plain class internally, and want it to "path" with the
plain mapper.
- The AliasedInsp is now the first class "entity" for an AliasedClass,
and is passed around internally and used as attr._parententity
and such. it is the AliasedClass analogue for Mapper.
Mike Bayer [Sat, 24 Nov 2012 21:14:58 +0000 (16:14 -0500)]
Added a new exception to detect the case where two
subclasses are being loaded using with_polymorphic(),
each subclass contains a relationship attribute of the same
name, and eager loading is being applied to one or both.
This is an ongoing bug which can't be immediately fixed,
so since the results are usually wrong in any case it raises an
exception for now. 0.7 has the same issue, so an exception
raise here probably means the code was returning the wrong
data in 0.7. [ticket:2614]
Mike Bayer [Sat, 24 Nov 2012 00:32:41 +0000 (19:32 -0500)]
- adjust this test for the ugly reality of the "name normalize" backends, where because we've decided
that "lowercase" is the case insensitive casing, we can't distinguish between case insensitive/not
on a database that returns case-insensitive names as UPPERCASE, for names that are UPPERCASE.
[ticket:2615]
Mike Bayer [Fri, 23 Nov 2012 04:45:24 +0000 (23:45 -0500)]
- recognize that do_rollback() and do_commit() work with a DBAPI connection,
whereas the other do_rollback_twophase(), savepoint etc. work with
:class:`.Connection`. the context on these are different as twophase/savepoint
are available at the :class:`.Connection` level, whereas commit/rollback are needed
at a lower level as well. Rename the argument to "dbapi_connection" when the conneciton
is in fact the DBAPI interface.
- start thinking about being able to track "autocommit" vs. "commit", but not sure
we have a need for this yet.
- have Pool call out to a Dialect for all rollback/commit/close operations now. Pool
no longer calls DBAPI methods directly. May use this for a workaround for [ticket:2611]
- add a new Pool event reset() to allow the pool's reset of the connection to be intercepted.
- remove methods in Informix dialect which appear to be hardcoding some isolation
settings on new Transaction only; the isolation API should be implemented for Informix.
also removed "flag" for transaction commit/rollback being not available; this should
be based on server/DBAPI version and we will need someone with test access in order
to help determine how this should work
Diana Clarke [Thu, 22 Nov 2012 18:20:20 +0000 (13:20 -0500)]
second pass: increasing coverage, and commenting the "why" certain things are being tested (when I know) b/c it wasn't initially clear to me why case was being toggled everywhere, etc.