load_only when loading relatinoships from an instance

53 views
Skip to first unread message

Tony Cosentini

unread,
Jan 4, 2023, 3:15:02 AM1/4/23
to sqlalchemy
Hi,

This might be a strange question, but I tried to find this in the documentation to no avail.

Is it possible to use something like load_only to override which columns are loaded in when loading a relationship (as in, a relationship that is not loaded at first with the original query)?

Something like:
class ModelB:
  ...

class ModelA:
  model_b = relationship("ModelB")

model_a = session.query(ModelA).options(load_only(Model_b.only_field_i_want_in_the_future)).filter(ModelA.id==1).first()

It's a bit strange, but I want to ensure if someone loads the model_b property in the future, only specific columns are loaded in at first.

I can do this if I just query for model_b via the foreign key instead of using the relationship property, but I'd like to avoid that if possible.

Sorry if this question is a bit weird/confusing, it's kind of a strange use case.

Thanks,
Tony

Michael Bayer

unread,
Jan 4, 2023, 7:14:21 PM1/4/23
to sqlalchemy
yeah you can use defaultload.load_only


defaultload(ModelA.model_b).load_only(ModelB.only_field)

Tony Cosentini

unread,
Jan 4, 2023, 10:09:40 PM1/4/23
to sqlalchemy
Funny enough, this is what I tried. I just wrote up a small sample script using defaultload + load_only and sure enough it works. There must be something in the code base I'm working with that prevents the load_only bit from being applied. I'm pretty sure defaultload is woroking fine. I'll report back if I find it.

Thanks for clarifying!

Tony Cosentini

unread,
Jan 5, 2023, 1:27:24 AM1/5/23
to sqlalchemy
Ok, I was able to at least create a script that easily reproduces what I'm seeing - https://gist.github.com/tonycosentini/22f42455c5068898efa473760e4f65ed

We have some code that runs before our tests to ensure all the tables are empty. When that runs, load_only doesn't seem to work. It sounds bizarre, but that gist link contains a really short sample that reproduces the same behavior. I'm running 1.4.44.

Tony

Mike Bayer

unread,
Jan 5, 2023, 9:00:43 AM1/5/23
to noreply-spamdigest via sqlalchemy
the "b" object in question is not really "lazy loaded" in the usual sense here because it's already present in the session, that looks like an unexpire query.   the delete() might be just changing something where the issue comes down to a set-ordering issue, perhaps.     try adding session.expunge_all() before the query and see if that makes things look more expected.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
 
 
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.

Mike Bayer

unread,
Jan 5, 2023, 9:12:56 AM1/5/23
to noreply-spamdigest via sqlalchemy
not as much set-ordering as gc, most likely.

add populate_existing to the query, that also should force the lazy loader to take effect

Tony Cosentini

unread,
Jan 5, 2023, 9:39:09 AM1/5/23
to sqlalchemy
populate_existing doesn't change the behavior, but expunge_all does. The code works correctly now though - it's just our test setup/teardown that was causing trouble (although it does seem like weird behavior).

Thanks again for so much help with such a great library,
Tony
Reply all
Reply to author
Forward
0 new messages