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.com>wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
