Understandable - there is no reason to change how it works as long as its possible to eagerload with deferred keys. Someone who is doing my pattern of access isn't going to be lazyloading much anyway. Not asking for any radical change, just discussing.
On Nov 14, 12:23 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Nov 14, 2007, at 11:44 AM, Chris M wrote: > > > > >> not entirely true... we need to know those values in sqlalchemy - we > >> couldn't issue lazy loads > > > Not true at all. Maybe in the current implementation, but it isn't > > necessary whatsoever. Let's say you have class Thing, which is many to > > one to class Owner. If you want to lazyload relation "owner" later, > > all it would have to do is check if "owner" was present (or None) in > > the InstanceState. If that's the case, issue the SQL "SELECT <owner > > attributes> FROM owner_table WHERE <literal join criterion, > > owner_table.id = thing_table.owner_id>" and load the data into a new > > Owner object. I'm confused to why you need the actual key value for > > this? > > OK yes, im the one confused, we dont need foreign key attributes to > issue lazy loads. But keep in mind that in SA, we dont really > fundamentally care about "foreign key" attributes; we are far more > agnostic than that. we only care about "remote side" columns which > can be anything you put into the primaryjoin condition. so in any > case, we aren't in much of a position to guess which columns the user > wants accessible as attributes. even in the case of foreign keys > its very common that someone is using natural keys (like 'username') > and can save queries by making usage of them in their foreign-key state. > > > > >> properly issue flushes if we didnt keep > >> track of foreign key values (hm, maybe the flushes work). > > > I don't know how your flush implementation works, but I doubt that's > > necessary either... > > the mapper.save_obj() receives an instance thats attached to a > parent. the dependency steps in the flush have already identified the > parent's identifying columns (based, as usual, on the "primaryjoin", > doesnt even have to be a PK column), and "sychronized" the value of > those columns to the "remote side" attributes on the child object > (which are usually foreign keys, but again dont have to be). > save_obj() only gets the child, it has no knowledge of the parent > relation. it then loops through its attributes and issues an INSERT. > So in that case, the "remote" values are sitting on the child object > as regular attributes just like everything else. we can make it so > that those attributes are "hidden", like inside the _state or > elsewhere, or we could really go nuts and change how the dependency > synchronization work so that they return data directly to save_obj > (that would be a *really* big refactoring). SA just uses the > instance itself and its attributes to represent the full row of data > to be inserted. this is the most straightforward way to do it, > regular users can understand it, they can set the FK values themselves > if they want (and they do). so yes its not necessary...but IMO most > other approaches would be more complicated and less user-friendly for > no reason. I work with Hibernate which does *not* do it this way, > and its a pain in the ass if i just want to set a parent id without > loading the parent object and attaching it. A central tenet of SA is > that we arent trying to "hide" the database behind a huge shroud like > it doesnt exist - real world applications need access to foreign key > columns. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
