<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/python-packages/sqlalchemy.git/lib/sqlalchemy/util/langhelpers.py, branch pr/263</title>
<subtitle>github.com: zzzeek/sqlalchemy.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/'/>
<entry>
<title>- happy new year</title>
<updated>2016-01-29T16:20:22+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2016-01-29T16:20:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=859379e2fcc4506d036700ba1eca4c0ae526a8ee'/>
<id>859379e2fcc4506d036700ba1eca4c0ae526a8ee</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>- revert the change first made in a6fe4dc, as we are now generalizing</title>
<updated>2016-01-28T20:01:31+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2016-01-28T20:01:31+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=8a1e619fb20df1be6ad2e0c563e451e17eb17628'/>
<id>8a1e619fb20df1be6ad2e0c563e451e17eb17628</id>
<content type='text'>
the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.

The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.

The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'origin/pr/210'</title>
<updated>2015-11-30T16:40:44+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-11-30T16:40:44+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=e45e4aa97d96421173da19d63f433795dad6e4e9'/>
<id>e45e4aa97d96421173da19d63f433795dad6e4e9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>- convert wrap_callable() to a general purpose update_wrapper-like</title>
<updated>2015-10-29T18:28:00+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-10-29T18:25:58+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=e31211c578854d63128a30c036e40eee5c43edc7'/>
<id>e31211c578854d63128a30c036e40eee5c43edc7</id>
<content type='text'>
function; the caller still passes in the "wrapper"
- move tests for wrap_callable() to be generic util tests
- changelog for pullreq github:204
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
function; the caller still passes in the "wrapper"
- move tests for wrap_callable() to be generic util tests
- changelog for pullreq github:204
</pre>
</div>
</content>
</entry>
<entry>
<title>Update usages of getargspec to compat version.</title>
<updated>2015-10-29T18:09:15+00:00</updated>
<author>
<name>Jacob MacDonald</name>
<email>jaccarmac@gmail.com</email>
</author>
<published>2015-10-29T00:52:06+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=e8a5ed9c1cbc5e9f0aebffad5ea78abb16167778'/>
<id>e8a5ed9c1cbc5e9f0aebffad5ea78abb16167778</id>
<content type='text'>
The places inspect.getargspec was being used were causing problems for
newer Python versions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The places inspect.getargspec was being used were causing problems for
newer Python versions.
</pre>
</div>
</content>
</entry>
<entry>
<title>- wrap ColumnDefault empty arg callables like functools.wraps, setting __name__, __doc__, and __module__</title>
<updated>2015-10-15T02:46:33+00:00</updated>
<author>
<name>Martin J. Hsu</name>
<email>martin.hsu@gmail.com</email>
</author>
<published>2015-09-25T08:15:28+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=c7d04beeac6ad54d638afb01783dee2d769aef9d'/>
<id>c7d04beeac6ad54d638afb01783dee2d769aef9d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>- merge of ticket_3499 indexed access branch</title>
<updated>2015-08-17T21:07:10+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-08-17T20:43:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=ceeb033054f09db3eccbde3fad1941ec42919a54'/>
<id>ceeb033054f09db3eccbde3fad1941ec42919a54</id>
<content type='text'>
- The "hashable" flag on special datatypes such as :class:`.postgresql.ARRAY`,
:class:`.postgresql.JSON` and :class:`.postgresql.HSTORE` is now
set to False, which allows these types to be fetchable in ORM
queries that include entities within the row.  fixes #3499
- The Postgresql :class:`.postgresql.ARRAY` type now supports multidimensional
indexed access, e.g. expressions such as ``somecol[5][6]`` without
any need for explicit casts or type coercions, provided
that the :paramref:`.postgresql.ARRAY.dimensions` parameter is set to the
desired number of dimensions. fixes #3487
- The return type for the :class:`.postgresql.JSON` and :class:`.postgresql.JSONB`
when using indexed access has been fixed to work like Postgresql itself,
and returns an expression that itself is of type :class:`.postgresql.JSON`
or :class:`.postgresql.JSONB`.  Previously, the accessor would return
:class:`.NullType` which disallowed subsequent JSON-like operators to be
used. part of fixes #3503
- The :class:`.postgresql.JSON`, :class:`.postgresql.JSONB` and
:class:`.postgresql.HSTORE` datatypes now allow full control over the
return type from an indexed textual access operation, either ``column[someindex].astext``
for a JSON type or ``column[someindex]`` for an HSTORE type,
via the :paramref:`.postgresql.JSON.astext_type` and
:paramref:`.postgresql.HSTORE.text_type` parameters. also part of fixes #3503
- The :attr:`.postgresql.JSON.Comparator.astext` modifier no longer
calls upon :meth:`.ColumnElement.cast` implicitly, as PG's JSON/JSONB
types allow cross-casting between each other as well.  Code that
makes use of :meth:`.ColumnElement.cast` on JSON indexed access,
e.g. ``col[someindex].cast(Integer)``, will need to be changed
to call :attr:`.postgresql.JSON.Comparator.astext` explicitly.  This is
part of the refactor in references #3503 for consistency in operator
use.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- The "hashable" flag on special datatypes such as :class:`.postgresql.ARRAY`,
:class:`.postgresql.JSON` and :class:`.postgresql.HSTORE` is now
set to False, which allows these types to be fetchable in ORM
queries that include entities within the row.  fixes #3499
- The Postgresql :class:`.postgresql.ARRAY` type now supports multidimensional
indexed access, e.g. expressions such as ``somecol[5][6]`` without
any need for explicit casts or type coercions, provided
that the :paramref:`.postgresql.ARRAY.dimensions` parameter is set to the
desired number of dimensions. fixes #3487
- The return type for the :class:`.postgresql.JSON` and :class:`.postgresql.JSONB`
when using indexed access has been fixed to work like Postgresql itself,
and returns an expression that itself is of type :class:`.postgresql.JSON`
or :class:`.postgresql.JSONB`.  Previously, the accessor would return
:class:`.NullType` which disallowed subsequent JSON-like operators to be
used. part of fixes #3503
- The :class:`.postgresql.JSON`, :class:`.postgresql.JSONB` and
:class:`.postgresql.HSTORE` datatypes now allow full control over the
return type from an indexed textual access operation, either ``column[someindex].astext``
for a JSON type or ``column[someindex]`` for an HSTORE type,
via the :paramref:`.postgresql.JSON.astext_type` and
:paramref:`.postgresql.HSTORE.text_type` parameters. also part of fixes #3503
- The :attr:`.postgresql.JSON.Comparator.astext` modifier no longer
calls upon :meth:`.ColumnElement.cast` implicitly, as PG's JSON/JSONB
types allow cross-casting between each other as well.  Code that
makes use of :meth:`.ColumnElement.cast` on JSON indexed access,
e.g. ``col[someindex].cast(Integer)``, will need to be changed
to call :attr:`.postgresql.JSON.Comparator.astext` explicitly.  This is
part of the refactor in references #3503 for consistency in operator
use.
</pre>
</div>
</content>
</entry>
<entry>
<title>- Fixed an issue where a particular base class within utils</title>
<updated>2015-07-21T00:35:04+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-07-21T00:35:04+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=575f080850a0a061ccb7ac40e3ea1fbf6b0fedf4'/>
<id>575f080850a0a061ccb7ac40e3ea1fbf6b0fedf4</id>
<content type='text'>
didn't implement ``__slots__``, and therefore meant all subclasses
of that class didn't either, negating the rationale for ``__slots__``
to be in use.  Didn't cause any issue except on IronPython
which apparently does not implement ``__slots__`` behavior compatibly
with cPython.
Fixes #3494
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
didn't implement ``__slots__``, and therefore meant all subclasses
of that class didn't either, negating the rationale for ``__slots__``
to be in use.  Didn't cause any issue except on IronPython
which apparently does not implement ``__slots__`` behavior compatibly
with cPython.
Fixes #3494
</pre>
</div>
</content>
</entry>
<entry>
<title>- Fixed an internal "memoization" routine for method types such</title>
<updated>2015-06-08T22:36:27+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-06-08T22:36:27+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=657be357de569ced699f44bdd96c6ba4e650b492'/>
<id>657be357de569ced699f44bdd96c6ba4e650b492</id>
<content type='text'>
that a Python descriptor is no longer used; repairs inspectability
of these methods including support for Sphinx documentation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
that a Python descriptor is no longer used; repairs inspectability
of these methods including support for Sphinx documentation.
</pre>
</div>
</content>
</entry>
<entry>
<title>- The warning emitted by the unicode type for a non-unicode type</title>
<updated>2015-03-31T19:10:42+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2015-03-31T18:40:21+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/sqlalchemy.git/commit/?id=5ed49f38c372360dbbe5c9e0c0e8fc502d034c0c'/>
<id>5ed49f38c372360dbbe5c9e0c0e8fc502d034c0c</id>
<content type='text'>
has been liberalized to warn for values that aren't even string
values, such as integers; previously, the updated warning system
of 1.0 made use of string formatting operations which
would raise an internal TypeError.   While these cases should ideally
raise totally, some backends like SQLite and MySQL do accept them
and are potentially in use by legacy code, not to mention that they
will always pass through if unicode conversion is turned off
for the target backend.
fixes #3346
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
has been liberalized to warn for values that aren't even string
values, such as integers; previously, the updated warning system
of 1.0 made use of string formatting operations which
would raise an internal TypeError.   While these cases should ideally
raise totally, some backends like SQLite and MySQL do accept them
and are potentially in use by legacy code, not to mention that they
will always pass through if unicode conversion is turned off
for the target backend.
fixes #3346
</pre>
</div>
</content>
</entry>
</feed>
