summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/compiler.py
Commit message (Collapse)AuthorAgeFilesLines
* Fixed bug where the expression system relied upon the ``str()``Mike Bayer2013-07-121-2/+6
| | | | | | | | | | | | form of a some expressions when referring to the ``.c`` collection on a ``select()`` construct, but the ``str()`` form isn't available since the element relies on dialect-specific compilation constructs, notably the ``__getitem__()`` operator as used with a Postgresql ``ARRAY`` element. The fix also adds a new exception class :class:`.UnsupportedCompilationError` which is raised in those cases where a compiler is asked to compile something it doesn't know how to. Also in 0.8.3. [ticket:2780]
* - Added new method to the :func:`.insert` constructMike Bayer2013-07-051-1/+3
| | | | | | | | | | :meth:`.Insert.from_select`. Given a list of columns and a selectable, renders ``INSERT INTO (table) (columns) SELECT ..``. While this feature is highlighted as part of 0.9 it is also backported to 0.8.3. [ticket:722] - The :func:`.update`, :func:`.insert`, and :func:`.delete` constructs will now interpret ORM entities as FROM clauses to be operated upon, in the same way that select() already does. Also in 0.8.3.
* Fixed bug when using multi-table UPDATE where a supplementalMike Bayer2013-07-021-2/+2
| | | | | | | table is a SELECT with its own bound parameters, where the positioning of the bound parameters would be reversed versus the statement itself when using MySQL's special syntax. [ticket:2768]
* - rework of correlation, continuing on #2668, #2746Mike Bayer2013-06-261-17/+73
| | | | | | | | | | | | | | | | | | | | | | | | - add support for correlations to propagate all the way in; because correlations require context now, need to make sure a select enclosure of any level takes effect any number of levels deep. - fix what we said correlate_except() was supposed to do when we first released #2668 - "the FROM clause is left intact if the correlated SELECT is not used in the context of an enclosing SELECT..." - it was not considering the "existing_froms" collection at all, and prohibited additional FROMs from being placed in an any() or has(). - add test for multilevel any() - lots of docs, including glossary entries as we really need to define "WHERE clause", "columns clause" etc. so that we can explain correlation better - based on the insight that a SELECT can correlate anything that ultimately came from an enclosing SELECT that links to this one via WHERE/columns/HAVING/ORDER BY, have the compiler keep track of the FROM lists that correspond in this way, link it to the asfrom flag, so that we send to _get_display_froms() the exact list of candidate FROMs to correlate. no longer need any asfrom logic in the Select() itself - preserve 0.8.1's behavior for correlation when no correlate options are given, not to mention 0.7 and prior's behavior of not propagating implicit correlation more than one level.. this is to reduce surprises/hard-to-debug situations when a user isn't trying to correlate anything.
* The resolution of :class:`.ForeignKey` objects to theirMike Bayer2013-06-231-1/+3
| | | | | | | | | | | | | | | | | | target :class:`.Column` has been reworked to be as immediate as possible, based on the moment that the target :class:`.Column` is associated with the same :class:`.MetaData` as this :class:`.ForeignKey`, rather than waiting for the first time a join is constructed, or similar. This along with other improvements allows earlier detection of some foreign key configuration issues. Also included here is a rework of the type-propagation system, so that it should be reliable now to set the type as ``None`` on any :class:`.Column` that refers to another via :class:`.ForeignKey` - the type will be copied from the target column as soon as that other column is associated, and now works for composite foreign keys as well. [ticket:1765]
* Merge branch 'ticket_2587'Mike Bayer2013-06-041-12/+117
|\ | | | | | | | | | | Conflicts: test/profiles.txt test/sql/test_selectable.py
| * - add coverage for result map rewritingMike Bayer2013-06-041-1/+6
| | | | | | | | | | - fix the result map rewriter for col mismatches, since the rewritten select at the moment typically has more columns than the original
| * - if the select() does not have use_labels on, then we just renderMike Bayer2013-06-041-0/+1
| | | | | | | | | | | | the joins as is, regardless of the dialect not supporting it. use_labels=True indicates a higher level of automation and also can maintain the labels between rewritten and not. use_labels=False indicates a manual use case.
| * - support for a__b_dc, i.e. two levels of nestingMike Bayer2013-06-041-4/+19
| |
| * and this commentMike Bayer2013-06-041-0/+4
| |
| * rewriting scheme now works.Mike Bayer2013-06-041-71/+43
| |
| * capture the really hard one in a test (hooray)Mike Bayer2013-06-041-1/+1
| |
| * OK this is the broken version, need to think a lot more about thisMike Bayer2013-06-031-1/+44
| |
| * working through tests....Mike Bayer2013-06-021-1/+13
| |
| * - figured out what the from_self() thing was about, part of query.statement, ↵Mike Bayer2013-06-021-7/+1
| | | | | | | | | | | | but would like to improve upon query.statement needing to do this
| * getting things to join without subqueries, but some glitches in the compiler ↵Mike Bayer2013-06-021-3/+8
| | | | | | | | | | | | step when we do query.count() are showing
| * implement join rewriting inside of visit_select(). Currently this is global ↵Mike Bayer2013-06-021-10/+64
| | | | | | | | or not based on fixing nested_join_translation as True or not.
* | - add changelog/migration noteMike Bayer2013-06-031-9/+9
| | | | | | | | - inline the label check
* | Merge branch 'master' into ticket_1068Mike Bayer2013-06-031-24/+13
|\ \ | |/
| * fix an errant str checkMike Bayer2013-05-261-1/+1
| |
| * a pass where we try to squash down as many list()/keys() combinationsMike Bayer2013-05-261-2/+2
| | | | | | | | as possible
| * - unicode literals need to just be handled differently if they have utf-8Mike Bayer2013-05-041-3/+3
| | | | | | | | | | encoded in them vs. unicode escaping. not worth figuring out how to combine these right now
| * - endless isinstance(x, str)s....Mike Bayer2013-04-281-12/+10
| |
| * import of "sqlalchemy" and "sqlalchemy.orm" works.Mike Bayer2013-04-271-13/+3
| |
| * - the raw 2to3 runMike Bayer2013-04-271-31/+32
| | | | | | | | - went through examples/ and cleaned out excess list() calls
* | magic accessors to the rescueMike Bayer2013-05-271-7/+7
| |
* | still not locating more nested expressions, may need to match on nameMike Bayer2013-05-271-11/+37
| |
* | attempt number one, doesn't detect though if the label in the order by is ↵Mike Bayer2013-05-271-3/+19
|/ | | | not directly present there.
* A major fix to the way in which a select() object producesMike Bayer2013-04-111-16/+18
| | | | | | | | | | | | | | | | | | | labeled columns when apply_labels() is used; this mode produces a SELECT where each column is labeled as in <tablename>_<columnname>, to remove column name collisions for a multiple table select. The fix is that if two labels collide when combined with the table name, i.e. "foo.bar_id" and "foo_bar.id", anonymous aliasing will be applied to one of the dupes. This allows the ORM to handle both columns independently; previously, 0.7 would in some cases silently emit a second SELECT for the column that was "duped", and in 0.8 an ambiguous column error would be emitted. The "keys" applied to the .c. collection of the select() will also be deduped, so that the "column being replaced" warning will no longer emit for any select() that specifies use_labels, though the dupe key will be given an anonymous label which isn't generally user-friendly. [ticket:2702]
* merge plus fix the test spelling tooMike Bayer2013-03-181-1/+1
|\
| * Fix typo.Richard Mitchell2013-03-181-1/+1
| |
* | no need to use getattr() hereMike Bayer2013-03-171-3/+3
|/
* Changed behavior of Select.correlate() to ignore correlations to froms that ↵Luke Cyca2013-03-071-7/+2
| | | | don't exist in the superquery.
* #2629Mike Bayer2013-01-251-0/+5
| | | | | insert().returning() raises an informative CompileError if attempted to compile on a dialect that doesn't support RETURNING.
* :class:`.Index` now supports arbitrary SQL expressions and/orMike Bayer2013-01-161-15/+26
| | | | | | | | functions, in addition to straight columns. Common modifiers include using ``somecolumn.desc()`` for a descending index and ``func.lower(somecolumn)`` for a case-insensitive index, depending on the capabilities of the target backend. [ticket:695]
* Tweaked the "REQUIRED" symbol used by the compiler to identifyMike Bayer2013-01-081-5/+14
| | | | | | INSERT/UPDATE bound parameters that need to be passed, so that it's more easily identifiable when writing custom bind-handling code. [ticket:2648]
* happy new year (see #2645)Diana Clarke2013-01-011-1/+1
|
* internally at least refer to multirow as "multivalues", to distinguish betweenMike Bayer2012-12-081-1/+1
| | | | | an INSERT that's used in executemany() as opposed to one which has a VALUES clause with multiple entries.
* - multivalued inserts, [ticket:2623]Mike Bayer2012-12-081-70/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - update "not supported" messages for empty inserts, mutlivalue inserts - rework the ValuesBase approach for multiple value sets so that stmt.parameters does store a list for multiple values; the _has_multiple_parameters flag now indicates which of the two modes the statement is within. it now raises exceptions if a subsequent call to values() attempts to call a ValuesBase with one mode in the style of the other mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode, and also if a multiple value is passed simultaneously with a kwargs set. Added tests for these error conditions - Calling values() multiple times in multivalue mode now extends the parameter list to include the new parameter sets. - add error/test if multiple *args were passed to ValuesBase.values() - rework the compiler approach for multivalue inserts, back to where _get_colparams() returns the same list of (column, value) as before, thereby maintaining the identical number of append() and other calls when multivalue is not enabled. In the case of multivalue, it makes a last-minute switch to return a list of lists instead of the single list. As it constructs the additional lists, the inline defaults and other calculated default parameters of the first parameter set are copied into the newly generated lists so that these features continue to function for a multivalue insert. Multivalue inserts now add no additional function calls to the compilation for regular insert constructs. - parameter lists for multivalue inserts now includes an integer index for all parameter sets. - add detailed documentation for ValuesBase.values(), including careful wording to describe the difference between multiple values and an executemany() call. - add a test for multivalue insert + returning - it works ! - remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
* merge latest defaultMike Bayer2012-12-081-1/+9
|\
| * visit_DECIMAL should include precision and scale (when provided) just like ↵Diana Clarke2012-12-031-1/+9
| | | | | | | | visit_NUMERIC see #2618
* | compiler: add support for multirow insertsIdan Kamara2012-12-061-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some databases support this syntax for inserts: INSERT INTO table (id, name) VALUES ('v1', 'v2'), ('v3', 'v4'); which greatly increases INSERT speed. It is now possible to pass a list of lists/tuples/dictionaries as the values param to the Insert construct. We convert it to a flat dictionary so we can continue using bind params. The above query will be converted to: INSERT INTO table (id, name) VALUES (:id, :name), (:id0, :name0); Currently only supported on postgresql, mysql and sqlite.
* | compiler: adjust _get_colparams to return the columns and parameters in ↵Idan Kamara2012-12-051-50/+49
|/ | | | separate lists
* just a pep8 pass of lib/sqlalchemy/sql/Diana Clarke2012-11-191-65/+62
|
* improve some autodoc linksMike Bayer2012-10-311-4/+4
|
* Fixed bug where keyword arguments passed toMike Bayer2012-10-241-3/+11
| | | | | | | | :meth:`.Compiler.process` wouldn't get propagated to the column expressions present in the columns clause of a SELECT statement. In particular this would come up when used by custom compilation schemes that relied upon special flags. [ticket:2593]
* The auto-correlation feature of :func:`.select`, andMike Bayer2012-10-221-1/+6
| | | | | | | | | by proxy that of :class:`.orm.Query`, will not take effect for a SELECT statement that is being rendered directly in the FROM list of the enclosing SELECT. Correlation in SQL only applies to column expressions such as those in the WHERE, ORDER BY, columns clause. [ticket:2595]
* - [feature] The Query can now load entity/scalar-mixedMike Bayer2012-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | "tuple" rows that contain types which aren't hashable, by setting the flag "hashable=False" on the corresponding TypeEngine object in use. Custom types that return unhashable types (typically lists) can set this flag to False. [ticket:2592] - [bug] Applying a column expression to a select statement using a label with or without other modifying constructs will no longer "target" that expression to the underlying Column; this affects ORM operations that rely upon Column targeting in order to retrieve results. That is, a query like query(User.id, User.id.label('foo')) will now track the value of each "User.id" expression separately instead of munging them together. It is not expected that any users will be impacted by this; however, a usage that uses select() in conjunction with query.from_statement() and attempts to load fully composed ORM entities may not function as expected if the select() named Column objects with arbitrary .label() names, as these will no longer target to the Column objects mapped by that entity. [ticket:2591]
* - [feature] Added "collation" parameter to allMike Bayer2012-10-101-9/+20
| | | | | | | | | | | String types. When present, renders as COLLATE <collation>. This to support the COLLATE keyword now supported by several databases including MySQL, SQLite, and Postgresql. [ticket:2276] - [change] The Text() type renders the length given to it, if a length was specified.
* - [feature] Various API tweaks to the "dialect"Mike Bayer2012-10-081-3/+6
| | | | | | | API to better support highly specialized systems such as the Akiban database, including more hooks to allow an execution context to access type processors.
View Lorry Controller Status