[sqlalchemy] Re: Moving (new) objects between sessions and committing?
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 you expunge it, then its detached. - SA seems to be acting as if the object is in a Detached state after the expunge, even though it was never committed and does not exist in the db. Why and can I somehow force this to Transient before the sessionB.add() or Pending, after? blow away the key.There's a make_transient() function in 0.6 which accomplishes this but its generally state = instance_state(obj); del state.key. the object still might have some attributes on it which you don't want, like primary key attributes that were assigned during the INSERT. You probably want to remove those too. Go through the object's attributes and ensure they all look like a row that hasn't yet been inserted. - why doesn't expunge remove all references to the original session/ state -- is there a way to do this? it removes session state but doesn't remove information about the row represented. Otherwise what state should it have ? - maybe I'm going about this completely wrong... any other method I should be using? You probably shouldn't put things into the session that don't represent rows you'd like to see in your database - right now it seems like you're issuing needless SQL and throwing it away. Thanks in advance and regards, Pat Deegan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 append/remove/set
operations can have the information they need continue down the chain of
events without exiting prematurely. Such as this test below:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
stuff = relation(Stuff, backref=parent)
class Stuff(Base):
__tablename__ = 'stuff'
id = Column(Integer, primary_key=True)
parent_id = Column(Integer, ForeignKey('parent.id'))
p1 = Parent()
p2 = Parent()
s1 = Stuff()
p1.stuff.append(s1)
p2.stuff.append(s1)
assert s1.parent is p2
assert s1 not in p1.stuff
assert s1 in p2.stuff
can be made to pass if we say this:
Index: lib/sqlalchemy/orm/attributes.py
===
--- lib/sqlalchemy/orm/attributes.py(revision 5901)
+++ lib/sqlalchemy/orm/attributes.py(working copy)
@@ -679,9 +679,6 @@
collection.append_with_event(value, initiator)
def remove(self, state, value, initiator, passive=PASSIVE_OFF):
-if initiator is self:
-return
-
collection = self.get_collection(state, passive=passive)
if collection is PASSIVE_NORESULT:
self.fire_remove_event(state, value, initiator)
so some more complete way of not exiting the event loop too soon would
need to be implemented.
Jason, any comments on this ?
jean-philippe dutreve wrote:
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 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 some kind of operation like
reparent_item()
that would move anobjectfrom 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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on
business
rules formovingan item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA
remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is
still
in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from
working
properly with list subclasses like ordering_list (or any SA
list-based
collection). I think it's fixed in Python 3.0, not sure if the fix
was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options,
[sqlalchemy] Re: moving an object
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 going to work for all situations - in any case its a
pretty significant behavioral change.
On Apr 18, 2009, at 5:12 AM, jean-philippe dutreve wrote:
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 append/remove/set
operations can have the information they need continue down the
chain of
events without exiting prematurely. Such as this test below:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
stuff = relation(Stuff, backref=parent)
class Stuff(Base):
__tablename__ = 'stuff'
id = Column(Integer, primary_key=True)
parent_id = Column(Integer, ForeignKey('parent.id'))
p1 = Parent()
p2 = Parent()
s1 = Stuff()
p1.stuff.append(s1)
p2.stuff.append(s1)
assert s1.parent is p2
assert s1 not in p1.stuff
assert s1 in p2.stuff
can be made to pass if we say this:
Index: lib/sqlalchemy/orm/attributes.py
===
--- lib/sqlalchemy/orm/attributes.py(revision 5901)
+++ lib/sqlalchemy/orm/attributes.py(working copy)
@@ -679,9 +679,6 @@
collection.append_with_event(value, initiator)
def remove(self, state, value, initiator, passive=PASSIVE_OFF):
-if initiator is self:
-return
-
collection = self.get_collection(state, passive=passive)
if collection is PASSIVE_NORESULT:
self.fire_remove_event(state, value, initiator)
so some more complete way of not exiting the event loop too soon
would
need to be implemented.
Jason, any comments on this ?
jean-philippe dutreve wrote:
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 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 some kind of operation like
reparent_item()
that would move anobjectfrom 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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on
business
rules formovingan item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for
instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA
remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is
still
in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from
working
properly with list subclasses like ordering_list (or any SA
list-based
collection). I think it's fixed in Python 3.0, not sure if
the fix
was
backported to 2.x.
[sqlalchemy] Re: moving an object
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is still in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on business
rules for moving an item that would be difficult to encapsulate in a common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is still in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 accountA anymore (entry.account_id
has changed). This end result should be reflected in memory just after
the change too (i.e. before commit).
On Apr 6, 1:10 pm, Mike Conley mconl...@gmail.com wrote:
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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on business
rules for moving an item that would be difficult to encapsulate in a common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries # false, entry is still in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on business
rules for moving an item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA
remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is still
in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix
was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 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 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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on business
rules for moving an item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA
remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries # false, entry is still
in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix
was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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 prematurely. Such as this test below:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
stuff = relation(Stuff, backref=parent)
class Stuff(Base):
__tablename__ = 'stuff'
id = Column(Integer, primary_key=True)
parent_id = Column(Integer, ForeignKey('parent.id'))
p1 = Parent()
p2 = Parent()
s1 = Stuff()
p1.stuff.append(s1)
p2.stuff.append(s1)
assert s1.parent is p2
assert s1 not in p1.stuff
assert s1 in p2.stuff
can be made to pass if we say this:
Index: lib/sqlalchemy/orm/attributes.py
===
--- lib/sqlalchemy/orm/attributes.py(revision 5901)
+++ lib/sqlalchemy/orm/attributes.py(working copy)
@@ -679,9 +679,6 @@
collection.append_with_event(value, initiator)
def remove(self, state, value, initiator, passive=PASSIVE_OFF):
-if initiator is self:
-return
-
collection = self.get_collection(state, passive=passive)
if collection is PASSIVE_NORESULT:
self.fire_remove_event(state, value, initiator)
so some more complete way of not exiting the event loop too soon would
need to be implemented.
Jason, any comments on this ?
jean-philippe dutreve wrote:
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 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 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 inserting and removing the entry in a single
operation. I can imagine that there would be many variations on
business
rules for moving an item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
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 contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA
remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries # false, entry is
still
in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from
working
properly with list subclasses like ordering_list (or any SA
list-based
collection). I think it's fixed in Python 3.0, not sure if the fix
was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: moving an object
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'),
order_by=[table_entries.c.position],
passive_deletes='all', cascade='save-update',
backref=backref('account', lazy=False),
),
))
I'd like to move an entry from accountA to accountB and let SA remove
the link between the entry and accountA:
entry = accountA.entries[0]
insort_right(accountB.entries, entry)
assert not entry in accountA.entries# false, entry is still in
accountA
It is possible?
Try removing the entry from accountA:
entry = accountA.pop(0)
...
Also beware that bisect insort has a bug that prevents it from working
properly with list subclasses like ordering_list (or any SA list-based
collection). I think it's fixed in Python 3.0, not sure if the fix was
backported to 2.x.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Moving On
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 continue to evolve, and particularly satisfying to see things I've started (e.g. AutoCode) being taken forward. Just of late, I've been reassessing priorities in my life, and open source development isn't going to be a big one going forward. In fact, I may even be giving up the computer completely for a year or two and going travelling. I'll be unsubscribing from the mailing list in a couple of days, although I'm happy to receive SA related emails at my personal address, for the next couple of months at least. Thanks for the interesting times, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Moving On
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 things I've started (e.g. AutoCode) being taken forward. Just of late, I've been reassessing priorities in my life, and open source development isn't going to be a big one going forward. In fact, I may even be giving up the computer completely for a year or two and going travelling. I'll be unsubscribing from the mailing list in a couple of days, although I'm happy to receive SA related emails at my personal address, for the next couple of months at least. Thanks for the interesting times, Paul Hi Paul, Thanks for all of your great work on SA and best of luck with the new road ahead. All the best, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Moving On
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 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 things I've started (e.g. AutoCode) being taken forward. Just of late, I've been reassessing priorities in my life, and open source development isn't going to be a big one going forward. In fact, I may even be giving up the computer completely for a year or two and going travelling. I'll be unsubscribing from the mailing list in a couple of days, although I'm happy to receive SA related emails at my personal address, for the next couple of months at least. Thanks for the interesting times, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Moving On
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 [EMAIL PROTECTED] 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 things I've started (e.g. AutoCode) being taken forward. Just of late, I've been reassessing priorities in my life, and open source development isn't going to be a big one going forward. In fact, I may even be giving up the computer completely for a year or two and going travelling. I'll be unsubscribing from the mailing list in a couple of days, although I'm happy to receive SA related emails at my personal address, for the next couple of months at least. Thanks for the interesting times, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
