I would like to ask whats the difference between
for row in session.Query(Model1): pass
and
for row in session.Query(Model1).all(): pass
is the first somehow an iterator bombarding your DB with single queries and the latter "eager" queries the whole thing as a list (like range(x) vs xrange(x)) ?
all() method. The Query object, when asked to return full entities, will deduplicate entries based on primary key, meaning if the same primary key value would appear in the results more than once, only one object of that primary key would be present.
Advertisements. All SELECT statements generated by SQLAlchemy ORM are constructed by Query object. It provides a generative interface, hence successive calls return a new Query object, a copy of the former with additional criteria and options associated with it.
If you want to view your data in a more schema-centric view (as used in SQL), use Core. If you have data for which business objects are not needed, use Core. If you view your data as business objects, use ORM. If you are building a quick prototype, use ORM.
SQLAlchemy is very, very fast. It's just that users tend to be unaware of just how much functionality is being delivered, and confuse an ORM result set with that of a raw database cursor.
Nope, there is no difference in DB traffic. The difference is just that for row in session.Query(Model1)
does the ORM work on each row when it is about to give it to you, while for row in session.Query(Model1).all()
does the ORM work on all rows, before starting to give them to you.
Note that q.all()
is just sugar for list(q)
, i.e. collecting everything yielded by the generator into a list. Here is the source code for it, in the Query
class (find def all
in the linked source):
def all(self): """Return the results represented by this ``Query`` as a list. This results in an execution of the underlying query. """ return list(self)
... where self
, the query object, is an iterable, i.e. has an __iter__
method.
So logically the two ways are exactly the same in terms of DB traffic; both end up calling query.__iter__()
to get a row iterator, and next()
ing their way through it.
The practical difference is that the former can start giving you rows as soon as their data has arrived, “streaming” the DB result set to you, with less memory use and latency. I can't state for sure that all the current engine implementations do that (I hope they do!). In any case the latter version prevents that efficiency, for no good reason.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With