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.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
-~----------~----~----~----~------~----~------~--~---
