@@ -385,6 +385,45 @@ def __init__(self,
385
385
returning = None ,
386
386
return_defaults = False ,
387
387
** kwargs ):
388
+ """Construct an :class:`.Insert` object.
389
+
390
+ Similar functionality is available via the
391
+ :meth:`~.TableClause.insert` method on
392
+ :class:`~.schema.Table`.
393
+
394
+ :param table: :class:`.TableClause` which is the subject of the insert.
395
+
396
+ :param values: collection of values to be inserted; see
397
+ :meth:`.Insert.values` for a description of allowed formats here.
398
+ Can be omitted entirely; a :class:`.Insert` construct will also
399
+ dynamically render the VALUES clause at execution time based on
400
+ the parameters passed to :meth:`.Connection.execute`.
401
+
402
+ :param inline: if True, SQL defaults will be compiled 'inline' into the
403
+ statement and not pre-executed.
404
+
405
+ If both `values` and compile-time bind parameters are present, the
406
+ compile-time bind parameters override the information specified
407
+ within `values` on a per-key basis.
408
+
409
+ The keys within `values` can be either :class:`~sqlalchemy.schema.Column`
410
+ objects or their string identifiers. Each key may reference one of:
411
+
412
+ * a literal data value (i.e. string, number, etc.);
413
+ * a Column object;
414
+ * a SELECT statement.
415
+
416
+ If a ``SELECT`` statement is specified which references this
417
+ ``INSERT`` statement's table, the statement will be correlated
418
+ against the ``INSERT`` statement.
419
+
420
+ .. seealso::
421
+
422
+ :ref:`coretutorial_insert_expressions` - SQL Expression Tutorial
423
+
424
+ :ref:`inserts_and_updates` - SQL Expression Tutorial
425
+
426
+ """
388
427
ValuesBase .__init__ (self , table , values , prefixes )
389
428
self ._bind = bind
390
429
self .select = None
@@ -468,6 +507,108 @@ def __init__(self,
468
507
returning = None ,
469
508
return_defaults = False ,
470
509
** kwargs ):
510
+ """Construct an :class:`.Update` object.
511
+
512
+ E.g.::
513
+
514
+ from sqlalchemy import update
515
+
516
+ stmt = update(users).where(users.c.id==5).\\
517
+ values(name='user #5')
518
+
519
+ Similar functionality is available via the
520
+ :meth:`~.TableClause.update` method on
521
+ :class:`.Table`::
522
+
523
+ stmt = users.update().\\
524
+ where(users.c.id==5).\\
525
+ values(name='user #5')
526
+
527
+ :param table: A :class:`.Table` object representing the database
528
+ table to be updated.
529
+
530
+ :param whereclause: Optional SQL expression describing the ``WHERE``
531
+ condition of the ``UPDATE`` statement. Modern applications
532
+ may prefer to use the generative :meth:`~Update.where()`
533
+ method to specify the ``WHERE`` clause.
534
+
535
+ The WHERE clause can refer to multiple tables.
536
+ For databases which support this, an ``UPDATE FROM`` clause will
537
+ be generated, or on MySQL, a multi-table update. The statement
538
+ will fail on databases that don't have support for multi-table
539
+ update statements. A SQL-standard method of referring to
540
+ additional tables in the WHERE clause is to use a correlated
541
+ subquery::
542
+
543
+ users.update().values(name='ed').where(
544
+ users.c.name==select([addresses.c.email_address]).\\
545
+ where(addresses.c.user_id==users.c.id).\\
546
+ as_scalar()
547
+ )
548
+
549
+ .. versionchanged:: 0.7.4
550
+ The WHERE clause can refer to multiple tables.
551
+
552
+ :param values:
553
+ Optional dictionary which specifies the ``SET`` conditions of the
554
+ ``UPDATE``. If left as ``None``, the ``SET``
555
+ conditions are determined from those parameters passed to the
556
+ statement during the execution and/or compilation of the
557
+ statement. When compiled standalone without any parameters,
558
+ the ``SET`` clause generates for all columns.
559
+
560
+ Modern applications may prefer to use the generative
561
+ :meth:`.Update.values` method to set the values of the
562
+ UPDATE statement.
563
+
564
+ :param inline:
565
+ if True, SQL defaults present on :class:`.Column` objects via
566
+ the ``default`` keyword will be compiled 'inline' into the statement
567
+ and not pre-executed. This means that their values will not
568
+ be available in the dictionary returned from
569
+ :meth:`.ResultProxy.last_updated_params`.
570
+
571
+ If both ``values`` and compile-time bind parameters are present, the
572
+ compile-time bind parameters override the information specified
573
+ within ``values`` on a per-key basis.
574
+
575
+ The keys within ``values`` can be either :class:`.Column`
576
+ objects or their string identifiers (specifically the "key" of the
577
+ :class:`.Column`, normally but not necessarily equivalent to
578
+ its "name"). Normally, the
579
+ :class:`.Column` objects used here are expected to be
580
+ part of the target :class:`.Table` that is the table
581
+ to be updated. However when using MySQL, a multiple-table
582
+ UPDATE statement can refer to columns from any of
583
+ the tables referred to in the WHERE clause.
584
+
585
+ The values referred to in ``values`` are typically:
586
+
587
+ * a literal data value (i.e. string, number, etc.)
588
+ * a SQL expression, such as a related :class:`.Column`,
589
+ a scalar-returning :func:`.select` construct,
590
+ etc.
591
+
592
+ When combining :func:`.select` constructs within the values
593
+ clause of an :func:`.update` construct,
594
+ the subquery represented by the :func:`.select` should be
595
+ *correlated* to the parent table, that is, providing criterion
596
+ which links the table inside the subquery to the outer table
597
+ being updated::
598
+
599
+ users.update().values(
600
+ name=select([addresses.c.email_address]).\\
601
+ where(addresses.c.user_id==users.c.id).\\
602
+ as_scalar()
603
+ )
604
+
605
+ .. seealso::
606
+
607
+ :ref:`inserts_and_updates` - SQL Expression
608
+ Language Tutorial
609
+
610
+
611
+ """
471
612
ValuesBase .__init__ (self , table , values , prefixes )
472
613
self ._bind = bind
473
614
self ._returning = returning
0 commit comments