Another beta! In this release I added one more significant change, hence we'll give it some time as "beta". The feature is known as "subquery eager loading", and it is a built-in version of the "disjoint eager loading" example at http://www.sqlalchemy.org/trac/wiki/UsageRecipes/DisjointEagerLoading - related collections are loaded in a separate execute call, but still using a JOIN upwards to the parent query so that the collections contents for the full set of parent objects is loaded at once. This improves on the existing "joined" eager loading by removing the full parent columns from the query and allowing the usage of an inner join in all cases. The still-existing "eagerload" and "eagerload_all" functions have new names as "joinedload" and "joinedload_all", and are joined by "subqueryload" and "subqueryload_all", and the "lazy" argument on relationship() now accepts the names "select", "joined", "subquery", "noload" and "dynamic" (as well as the old True/False/None values).
The construction of subqueryload led to a handful of additional fixes to Query involving difficult self-referential joining scenarios and some behavior of query options. Thanks to everyone for testing the existing betas so far, 0.6beta1 had over 10K downloads and beta2 around 2K. Download SQLAlchemy 0.6beta3 at: http://www.sqlalchemy.org/download.html 0.6beta3 ======== - orm - Major feature: Added new "subquery" loading capability to relationship(). This is an eager loading option which generates a second SELECT for each collection represented in a query, across all parents at once. The query re-issues the original end-user query wrapped in a subquery, applies joins out to the target collection, and loads all those collections fully in one result, similar to "joined" eager loading but using all inner joins and not re-fetching full parent rows repeatedly (as most DBAPIs seem to do, even if columns are skipped). Subquery loading is available at mapper config level using "lazy='subquery'" and at the query options level using "subqueryload(props..)", "subqueryload_all(props...)". [ticket:1675] - To accomodate the fact that there are now two kinds of eager loading available, the new names for eagerload() and eagerload_all() are joinedload() and joinedload_all(). The old names will remain as synonyms for the foreseeable future. - The "lazy" flag on the relationship() function now accepts a string argument for all kinds of loading: "select", "joined", "subquery", "noload" and "dynamic", where the default is now "select". The old values of True/ False/None still retain their usual meanings and will remain as synonyms for the foreseeable future. - Added with_hint() method to Query() construct. This calls directly down to select().with_hint() and also accepts entities as well as tables and aliases. See with_hint() in the SQL section below. [ticket:921] - Fixed bug in Query whereby calling q.join(prop).from_self(...). join(prop) would fail to render the second join outside the subquery, when joining on the same criterion as was on the inside. - Fixed bug in Query whereby the usage of aliased() constructs would fail if the underlying table (but not the actual alias) were referenced inside the subquery generated by q.from_self() or q.select_from(). - Fixed bug which affected all eagerload() and similar options such that "remote" eager loads, i.e. eagerloads off of a lazy load such as query(A).options(eagerload(A.b, B.c)) wouldn't eagerload anything, but using eagerload("b.c") would work fine. - Query gains an add_columns(*columns) method which is a multi- version of add_column(col). add_column(col) is future deprecated. - Query.join() will detect if the end result will be "FROM A JOIN A", and will raise an error if so. - Query.join(Cls.propname, from_joinpoint=True) will check more carefully that "Cls" is compatible with the current joinpoint, and act the same way as Query.join("propname", from_joinpoint=True) in that regard. - sql - Added with_hint() method to select() construct. Specify a table/alias, hint text, and optional dialect name, and "hints" will be rendered in the appropriate place in the statement. Works for Oracle, Sybase, MySQL. [ticket:921] - Fixed bug introduced in 0.6beta2 where column labels would render inside of column expressions already assigned a label. [ticket:1747] - postgresql - The psycopg2 dialect will log NOTICE messages via the "sqlalchemy.dialects.postgresql" logger name. [ticket:877] - the TIME and TIMESTAMP types are now availble from the postgresql dialect directly, which add the PG-specific argument 'precision' to both. 'precision' and 'timezone' are correctly reflected for both TIME and TIMEZONE types. [ticket:997] - mysql - No longer guessing that TINYINT(1) should be BOOLEAN when reflecting - TINYINT(1) is returned. Use Boolean/ BOOLEAN in table definition to get boolean conversion behavior. [ticket:1752] - oracle - The Oracle dialect will issue VARCHAR type definitions using character counts, i.e. VARCHAR2(50 CHAR), so that the column is sized in terms of characters and not bytes. Column reflection of character types will also use ALL_TAB_COLUMNS.CHAR_LENGTH instead of ALL_TAB_COLUMNS.DATA_LENGTH. Both of these behaviors take effect when the server version is 9 or higher - for version 8, the old behaviors are used. [ticket:1744] - declarative - Using a mixin won't break if the mixin implements an unpredictable __getattribute__(), i.e. Zope interfaces. [ticket:1746] - Using @classdecorator and similar on mixins to define __tablename__, __table_args__, etc. now works if the method references attributes on the ultimate subclass. [ticket:1749] - relationships and columns with foreign keys aren't allowed on declarative mixins, sorry. [ticket:1751] - ext - The sqlalchemy.orm.shard module now becomes an extension, sqlalchemy.ext.horizontal_shard. The old import works with a deprecation warning. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
