Hi Michael,

As always, thank you very much for your dedication :)
I recognize that I am always trying to reach the edges of your wonderful
library.

That example is just a sample of what I am trying to accomplish:
Some sort of "virtual" column/relationship, that it is not mapped to any
column, but it can be batch-loaded in a set of instances using a
carefully-crafted contains_eager.
That way, using a descriptor, if the attribute is not in __dict__ (as you
just pointed), i can craft a CTE to fetch the attribute.
Or, if the user knows better, will use a with_transformation on top of his
query to fetch the attribute for all the queried instances.

Thank you again!

2013/1/23 Michael Bayer <mike...@zzzcomputing.com>

>
> On Jan 23, 2013, at 4:28 PM, Pau Tallada wrote:
>
> Hi,
>
> I have prepared a sample of code to ilustrate this behaviour :)
>
> Summarizing:
>
> session.expunge_all()
> n2 =
> session.query(Node).filter_by(name='n2').options(joinedload('ancestors')).one()
> print n2.ancestors
>
>
> AND:
>
> session.expunge_all()
> n2 = session.query(Node).filter_by(name='n2').one()
> n2 =
> session.query(Node).filter_by(name='n2').options(joinedload('ancestors')).one()
> print n2.ancestors
>
>
> do NOT produce the same result when the collection is lazy='noload'.
>
> In the latter, the collection is empty, even after we fetch its contents
> with a joinedload.
>
>
> Ah well without actually running it, I can say that the joinedload for the
> second case won't have an effect like that, since "n2.ancestors" is already
> "loaded", as the effect of "noload" is to populate the attribute with an
> empty collection (or None for a scalar).   "noload" is not very widely used
> and was sort of an added-in strategy from very early versions.
>
> What it appears like you're looking for on "anscestors" is just the
> default "lazy" loader.  Above, when you load "n2" without any options,
> n2.anscestors will not be present in n2.__dict__ at all, and that's what
> "unloaded" means.   Hitting it again with the joinedload() should populate
> the collection.
>
> But there's not really a built in system of, "don't load this mapped
> attribute, but also don't load anything when touched".   So if you stuck
> with "noload", you'd have to call expire() on "ancestors" first in order to
> get a subsequent loader to populate it.
>
> I guess if I really wanted an attribute like this, I'd need to wrap it
> under a @property:
>
> @property
> def ancestors(self):
>     if "_ancestors" in self.__dict__:
>         return self._anscestors
>    else:
>         return None
>
> if I think of a better way I'll let you know.
>
>
>
>
>
>
>
> 2013/1/23 Pau Tallada <tall...@pic.es>
>
>> Ok, thank you very much :D
>>
>> I'll keep poking, and i'll try to provide a sample code :P
>>
>>
>> 2013/1/23 Michael Bayer <mike...@zzzcomputing.com>
>>
>>>
>>> On Jan 23, 2013, at 6:49 AM, Pau Tallada wrote:
>>>
>>> >
>>> > One final comment. With the contains_eager query, the instances that
>>> are part of the collection are retrieved from the database but not stored
>>> on the identity_map. Is that also the expected behaviour, isn't it?
>>>
>>> I need to read your whole email more closely but on this point, that's
>>> not true at all.  Every object that the Session loads from the database
>>> goes directly to the identity map.    The identity map is weak referencing,
>>> so if no other references remain to a particular object, it will disappear
>>> from the identity map also, but that implies that object is not accessible
>>> anywhere else either.
>>>
>>> Since it seems like you've been poking around, you might want to
>>> continue poking around some more given that information until I have time
>>> to look at the rest of your email.
>>>
>>>
>>> --
>>> 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.
>>>
>>>
>>
>>
>> --
>> ----------------------------------
>> Pau Tallada Crespí
>> Dep. d'Astrofísica i Cosmologia
>> Port d'Informació Científica (PIC)
>> Tel: +34 93 586 8233
>> ----------------------------------
>>
>>
>
>
> --
> ----------------------------------
> Pau Tallada Crespí
> Dep. d'Astrofísica i Cosmologia
> Port d'Informació Científica (PIC)
> Tel: +34 93 586 8233
> ----------------------------------
>
>
> --
> 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.
> <noload.py>
>
>
>  --
> 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.
>



-- 
----------------------------------
Pau Tallada Crespí
Dep. d'Astrofísica i Cosmologia
Port d'Informació Científica (PIC)
Tel: +34 93 586 8233
----------------------------------

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

Reply via email to