psychogenic wrote:
My questions are:
- why does the instance state think it doesn't need to insert this
object, that was never committed?
it was INSERTed in your other session. You probably didn't commit the
transaction. The object then gets the key and such is now persistent,
until
Hi, any chance to have a fix for this?
On 6 avr, 17:16, Michael Bayer mike...@zzzcomputing.com wrote:
OK in fact this can possibly be implemented if the initiator passed
during attribute mutation operations consisted of not just an
AttributeImpl but also a target instance, so that
if we had some help. the next time I have time to work on SQLAlchemy
the 0.6 release is my top priority. this particular issue is a
behavioral quirk with multiple, straightforward workarounds, and it
also not entirely clear if continuing event chains in the manner I'm
proposing is even
Currently, I use accountA.remove(entry) and I have rewritten insort to
bypass the bug you say.
So, AFAIK, whereas an entry has only one account (via
entry.account_id), SA can't remove the first relation.
It's dangerous, because if developer forget to remove the first
relation, the entry is
So, we would like SA to have some kind of operation like reparent_item()
that would move an object from one relation to another.
It seems to me that this is is better handled as a piece of application
business logic. In this case, provide a move_entry() function that
properly encapsulates
The object doesn't move from one relation to another : this is the
same relation 'entries' but on a different parent. This is common to
any parent.child pattern, not a business specific case.
The current behavior is not consistent because as soon as we commit()
+ refresh(), the object is not on
im slightly confused. the backref should be automatically reparenting,
not sure if ordering_list interferes with that, but in any case after you
flush()/expire() or commit(), it will definitely happen since all
collections will load fresh.
Mike Conley wrote:
So, we would like SA to have
It would be fine/safe that accountA has entry removed BEFORE any
reload (with explicit refresh/expire/commit). I can't remember, but a
previous version of SA had this behavior.
On Apr 6, 4:42 pm, Michael Bayer mike...@zzzcomputing.com wrote:
im slightly confused. the backref should be
OK in fact this can possibly be implemented if the initiator passed
during attribute mutation operations consisted of not just an
AttributeImpl but also a target instance, so that append/remove/set
operations can have the information they need continue down the chain of
events without exiting
jean-philippe dutreve wrote:
Hi all,
I wonder if SA can handle this use case:
An Account can contain Entries ordered by 'position' attribute.
mapper(Account, table_accounts, properties = dict(
entries = relation(Entry, lazy=True, collection_class=ordering_list
('position'),
have fun
svilen
On Tuesday 24 June 2008 22:37:08 Paul Johnston wrote:
Hi,
I've had fun over the last 18 months doing odd bits of work on
SQLAlchemy. It works pretty damn well on MSSQL now, although I
never did quite get all the unit tests nailed. It's been great
seeing the library
Paul Johnston wrote:
Hi,
I've had fun over the last 18 months doing odd bits of work on
SQLAlchemy. It works pretty damn well on MSSQL now, although I never did
quite get all the unit tests nailed. It's been great seeing the library
continue to evolve, and particularly satisfying to see
hi Paul -
Congrats on making some hard decisions. Thanks for all your help,
and good luck ! Your commit access remains open.
- mike
On Jun 24, 2008, at 3:37 PM, Paul Johnston wrote:
Hi,
I've had fun over the last 18 months doing odd bits of work on
SQLAlchemy. It works pretty
Hey I'll miss you Paul; thanks for all of your help with MSSQL and for being
the pyodbc trailblazer.
Good luck with whatever your new direction in life brings -- turning off the
computer and a taking bit of travel time sounds pretty appealing!
On Tue, Jun 24, 2008 at 3:37 PM, Paul Johnston
14 matches
Mail list logo
