Thanks Gaetan, I think I have enough to start extending to_dict(), now I just need to find some time :-)
> If you do implement this, please provide a separate patch for this as > I'm still undecided about its fate. I'd like input from more people on > this. Definitely! Since its the same piece of code I'll make "one with" and "one without". Cheers, Danny On Wed, Mar 25, 2009 at 21:19, Gaetan de Menten <[email protected]> wrote: > > On Wed, Mar 25, 2009 at 06:59, Danny Adair <[email protected]> wrote: >>>> Also: >>>> - Is there a simple way to build that "deep" tree automatically from >>>> my model, if I happen to want to resolve _all_ ManyToOne and OneToOne >>>> relationships in the entity? I don't have circular problems and just >>>> want "all". >>> >>> Not that I know of. It's not particularly hard to do though. >>> Introducing such behavior *might* be a good idea. Maybe if "deep == >>> True". What do people think about this? >> >> I think it's a great idea. :-) >> I'll put it in a patch. > > If you do implement this, please provide a separate patch for this as > I'm still undecided about its fate. I'd like input from more people on > this. > >>>> - Couldn't "exclude" be a nested dict like "deep", rather than a list? > >>> This makes a lot of sense. The current behavior is broken and we >>> should indeed add a mechanism to specify "deep" excludes. Patch >>> welcome too... > >> I'll write a patch that works for me - I don't understand the FIXME >> line (yet) so that deficiency might remain in my patched version. > > The thing is that SQLAlchemy do not force you to use the same names > for your object attributes as the names of the corresponding columns > in the mapped table. In the from_dict/to_dict context, we use > attribute names and not the raw column names (they'll be the same in > most cases but not always), but the remote_side argument gives us > column names, not attribute names, so they should be converted. The > same conversion is done in EntityDescriptor.primary_key_properties, so > a common method should probably be extracted. > >>>> (and just extended with the remote_side stuff) >>> >>> I'm not sure I understand what you mean here... >> >> I'm referring to the lines: >> fks = self.mapper.get_property(rname).remote_side >> exclude = [c.name for c in fks] > > Yep. Looking at the code, your sentence makes sense :) > >> where instead of "deep excludes" the back referrals get auto-excluded. >> That's useful behaviour and should be imho implicit once there are >> "deep excludes". > > You could be right. I'll have to think a bit more about this, though > I'm not fully awake yet... > > -- > Gaëtan de Menten > http://openhex.org > > > > -- Kind regards, Danny W. Adair Director Unfold Limited New Zealand Talk: +64 - 9 - 9555 101 Write: [email protected] Browse: www.unfold.co.nz Visit/Post: 41 Hihitahi Rise, Te Haumi, Paihia 0200, New Zealand "We are what we repeatedly do. Excellence, therefore, is not an act, but a habit." - Aristotle ============================== Caution The contents of this email and any attachments contain information which is CONFIDENTIAL to the recipient. If you are not the intended recipient, you must not read, use, distribute, copy or retain this email or its attachments. If you have received this email in error, please notify us immediately by return email or collect telephone call and delete this email. Thank you. We do not accept any responsibility for any changes made to this email or any attachment after transmission from us. ============================== --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
