On Dec 30, 2007, at 11:05 AM, Andreas Jung wrote:
> Hi, > > I habe a table where we store tree-ish data using a self-referential > mapper (same setup as within the SA docs using an id for the nodes > and a pointer back to the parent node given by its id)...this works > without a problem. > > Now comes the tricky part: a node from one tree can point to a node > within another tree for sharing a common subtree. In this example > tree 2 > is something like a "master" tree and tree 1 derives the subtree 'N' > from tree 2. The link between to nodes is a dedicated 'share_id' > where in this > particular case the row for node 'C' contains the id of node 'N' as > 'share_id'. > > > Tree 1 Tree 2 > > A M > / \ / \ > B C -----------> N O > / \ /\ > D E P Q > > > I am using this model since some years for the application (hand- > made Python code/SQL queries) but now I want to adopt it to SA. > > The basic question is how I would extend the configuration for the > self-referential mapper in order to make Tree 1 appear as: > > A > / \ > B N > / | |\ > D E P Q > > To make it more clear: when obtaining the list of children for node > 'A' > I want to get hold of the rows for the nodes 'B' and 'N', not 'B' > and 'C'. > So the node 'C' should be replaced with the node 'N' and its subtree. > > Any idea how to model this in a sane way using SA? without seeing much detail here it seems like youd just have a relation along "share_id", which im assuming is a different kind of relation than the one from A to B, and to "conceal" the C node and make it look like an N you could use a proxying class attribute. or you could do something similar at the SQL level by using a more elaborate "primaryjoin" condition from parent node to child node, which tests for the presence of "share_id" - possibly using a "viewonly" relation which is separate from the "persistence" relation if you also need to set up the "C" node attached to "A" explicitly for a flush operation. The best answer would come from your own code. What is the SQL you are currently using ? you should design your mappers against that. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
