| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Found using: https://github.com/intgr/topy
|
| |
|
|
|
|
|
|
|
| |
be used to manufacture objects that behave as though they were loaded
from a session, then detached. Attributes that aren't present
are marked as expired, and the object can be added to a Session
where it will act like a persistent one. fix #3017
|
| |
|
| |
|
| |
|
|
|
|
| |
not be superseded. both have a potential use.
|
|
|
|
|
|
|
|
|
|
| |
now can accomodate additional information about the "reason" for
the exception; the :class:`.Session` now adds some detail to it
when the exception occurs within an autoflush. This approach
is taken as opposed to combining :class:`.FlushError` with
a Python 3 style "chained exception" approach so as to maintain
compatibility both with Py2K code as well as code that already
catches ``IntegrityError`` or similar.
|
| |
|
|\
| |
| | |
Fix sessionmaker.__repr__
|
| |
| |
| | |
A comma separating 'class_' from the other args. It's still there even when kw is empty, which is syntactically correct.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
| |
- rework the event system so that event modules load after their
targets, dependencies are reversed
- create an improved strategy lookup system for the ORM
- rework the ORM to have very few import cycles
- move out "importlater" to just util.dependency
- other tricks to cross-populate modules in as clear a way as possible
|
|
|
|
|
|
|
|
| |
this is a dictionary where applications can store arbitrary
data local to a :class:`.Session`.
The contents of :attr:`.Session.info` can be also be initialized
using the ``info`` argument of :class:`.Session` or
:class:`.sessionmaker`.
|
|
|
|
| |
as possible
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
of :meth:`.Session.begin_nested` would fail to correctly
roll back the transaction when a flush error occurred, instead
raising its own exception while leaving the session still
pending a rollback. [ticket:2718]
|
|/
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the creation of strong references within the Session;
an object will no longer have an internal reference cycle
created if it's in the transient state or moves into the
detached state - the strong ref is created only when the
object is attached to a Session and is removed when the
object is detached. This makes it somewhat safer for an
object to have a `__del__()` method, even though this is
not recommended, as relationships with backrefs produce
cycles too. A warning has been added when a class with
a `__del__()` method is mapped.
[ticket:2708]
|
| |
|
|
|
|
|
|
|
|
|
| |
a rollback() before re-raising, so that the stack
trace is preserved from sys.exc_info() before entering
the rollback. This so that the traceback is preserved
when using coroutine frameworks which may have switched
contexts before the rollback function returns.
[ticket:2703]
|
|
|
|
|
|
|
|
| |
message for [ticket:2662]; after_commit() is called within "committed"
state, not prepared, and no SQL can be emitted for prepared or committed
- consolidate state assertions in session transaction, use just one
method
- add more unit tests for these assertions
|
|
|
|
|
|
|
|
|
|
| |
attempts to emit SQL on a Session within the after_commit()
handler, where there is not a viable transaction in progress.
[ticket:2662]
- rework how SessionTransaction maintains state, using symbols
instead.
- add lots of notes and cross-linking for session events.
- add a link to :func:`.select()` within :meth:`.FromClause.select`.
|
|
|
|
|
|
|
|
|
| |
if the given object was the subject of a :meth:`.Session.delete`
operation.
- An object that's deleted from a session will be de-associated with
that session fully after the transaction is committed, that is
the :func:`.object_session` function will return None.
[ticket:2658]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
- support annotations on Column where name isn't immediately present
|
|
|
|
| |
- it appears we can get rid of all those "XYZ_toplevel" names and use :doc:.
|
|
|
|
| |
- errant pdbs
|
|
|
|
|
|
| |
- begin consolidating docs for dialects to be more self contained
- add a separate section for "external" dialects
- not sure how we're going to go with this yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
state post-flush due to event listeners;
any states that are marked as "dirty" from an
attribute perspective, usually via column-attribute
set events within after_insert(), after_update(),
etc., will get the "history" flag reset
in all cases, instead of only those instances
that were part of the flush. This has the effect
that this "dirty" state doesn't carry over
after the flush and won't result in UPDATE
statements. A warning is emitted to this
effect; the set_committed_state()
method can be used to assign attributes on objects
without producing history events. [ticket:2582]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when unsupported methods are used inside the
"execute" portion of the flush. These are
the familiar methods add(), delete(), etc.
as well as collection and related-object
manipulations, as called within mapper-level
flush events
like after_insert(), after_update(), etc.
It's been prominently documented for a long
time that SQLAlchemy cannot guarantee
results when the Session is manipulated within
the execution of the flush plan,
however users are still doing it, so now
there's a warning. Maybe someday the Session
will be enhanced to support these operations
inside of the flush, but for now, results
can't be guaranteed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a deleted object in the identity map with another
object of the same primary key would raise a
"conflicting state" error on rollback(),
if the replaced primary key were established either
via non-unitofwork-established INSERT statement
or by primary key switch of another instance.
[ticket:2583]
|
|
|
|
| |
- don't even talk about metadata.bind in declarative
|
|
|
|
|
|
|
|
|
|
|
|
| |
that occurs within Session.commit(), such that the
extra state added by an after_flush() or
after_flush_postexec() hook is also flushed in a
subsequent flush, before the "commit" completes.
Subsequent calls to flush() will continue until
the after_flush hooks stop adding new state.
An "overflow" counter of 100 is also in place,
in the event of a broken after_flush() hook
adding new content each time. [ticket:2566]
|
|
|
|
|
|
|
|
| |
and after_transaction_end
allows tracking of new SessionTransaction objects.
If the object is inspected, can be used to determine
when a session first becomes active and when
it deactivates.
|
| |
|
|
|
|
| |
- rewrite tons of session docs
|
|
|
|
| |
- rewrite docs for session.execute()
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
that change object state as these aren't intended for public
use.
|
| |
|