sqlalchemy-tickets — trac tickets and updates forwarded to this list

Re: [Sqlalchemy-tickets] [sqlalchemy] #2716: table.tometadata(metadata) should copy column.info dictionary instead of referencing same dictionary

[sqlalchemy <mi...@zz...>]

#2716: table.tometadata(metadata) should copy column.info dictionary instead of
referencing same dictionary
----------------------------+----------------------------------
      Reporter:  kentbower  |      Owner:  zzzeek
          Type:  defect     |     Status:  new
      Priority:  high       |  Milestone:  0.9.0
     Component:  schema     |   Severity:  minor - half an hour
    Resolution:             |   Keywords:
Progress State:  in queue   |
----------------------------+----------------------------------
Changes (by zzzeek):

 * priority:  low => high
 * milestone:  0.8.xx => 0.9.0


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2716#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2788: matter for release relieved

[sqlalchemy <mi...@zz...>]

#2788: matter for release relieved
-----------------------------+-----------------------------------------
 Reporter:  JacquelineCovas  |           Owner:  zzzeek
     Type:  defect           |          Status:  new
 Priority:  low              |       Milestone:
Component:  cextensions      |        Severity:  no triage selected yet
 Keywords:                   |  Progress State:  awaiting triage
-----------------------------+-----------------------------------------
 {{{
 #!html
 <h1 style="text-align: center">Конфиденциальность и безопасность на веб-
 портале интим-услуг</h1>
 }}}
 На сегодняшний день интернет – это не только средство для обмена
 информацией, это и идеальный помощник для всех, кто желает развлечься.
 Сайты по предоставлению интим-услуг, сделают времяпровождение как можно
 более интересным и незабываемым. Нет предела фантазиям. [[br]] На
 интернет-сайте, предлагающем услуги интимного характера, подобраны лучшие
 проститутки киева. Не нем также существует возможность рассмотреть любую
 девушку и ознакомиться с стоимостью, предоставляемыми услугами и
 правилами. Естественно, к интим-услугам '''[http://escort-models.com
 проститутки киев]''' это будет либо какой-нибудь другой город захотят
 прибегнуть многие мужчины. А поводов для этого может быть масса: - ощутить
 себя желанным;- приятно порадовать партнеров по бизнесу либо же товарища;
 - избавиться от всяческих комплексов;- отдохнуть душой и телом;- получить
 новый опыт;- и, может быть, слегка поэкспериментировать. Многочисленные
 гости Киева, приезжая сюда посмотреть местные достопримечательности или по
 делам стремятся воспользоваться сексуальными услугами. Потому как
 проститутки украины всегда составят приятную компанию и не дадут гостям
 грустить в одиночестве, они могут приехать на несколько часов или же
 остаться на всю ночь. [[br]] Чтобы воспользоваться услугами несравненных
 леди необходимо зайти на сайт, отыскать приглянувшуюся девушку и по
 контактному телефону связаться с представителем компании. Также нужно
 будет указать место, где вы хотите встретиться с девушкой и промежуток
 времени. Все предпочтения строго соблюдаются. [[br]] Огромнейший плюс
 такого рода сервиса - тот факт, что если понадобились проститутки в киеве,
 то не нужно в поисках подозрительных услуг выезжать куда-либо. Всегда
 возможно прибегнуть к возможностям проверенного агентства. [[br]] Имея
 какое-то лишнее время, возможно просмотреть анкеты проституток киева. И
 тогда по определенным параметрам вполне можно отобрать девочек, услугами
 которых можно будет пользоваться регулярно. [[br]] Предлагающие
 сексуальные услуги агентства уровень обслуживания ставят на первое место.
 Мужчина должен оставаться доволен всегда. Лишь в таком случае вызывать
 девушек он будет вновь. [[br]] А если клиента весьма заинтересовала какая-
 то проститутка киев посещает он часто, то и ее услугами он станет
 пользоваться всегда. При этом ему могут предоставляться определенные
 скидки. [[br]] Популярность сексуальных услуг растет с каждым годом. Это
 объяснимо, потому как сейчас самая древнейшая профессия стала куда более
 доступной. Многочисленные странички в сети интернет представляют самые
 разные варианты интимных удовольствий: веб-камеры, чаты. Но, тем не менее,
 ничто не может сравниться с вызовом девушки на дом, поскольку здесь можно
 не просто расслабиться телом, а еще и мило пообщаться с приятной и
 симпатичной девушкой. Можно быть полностью уверенным в том, что обращаясь
 в проверенную и надежную компанию, секс-услуги выполняются на высшем
 уровне и все сведения о клиенте останутся конфиденциальными. [[br]]
 Прибегнуть к услугам проституток можно для себя, а также можно сделать
 приятный и незабываемый сюрприз деловым партнерам либо же другу. Эти
 сюрпризы будут оценены высоко.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2788>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2787: History state after commit

[sqlalchemy <mi...@zz...>]

#2787: History state after commit
------------------------------+--------------------------------
      Reporter:  harutune     |      Owner:  zzzeek
          Type:  defect       |     Status:  new
      Priority:  high         |  Milestone:  0.9.0
     Component:  orm          |   Severity:  major - 1-3 hours
    Resolution:               |   Keywords:  history attributes
Progress State:  in progress  |
------------------------------+--------------------------------

Comment (by harutune):

 Thank you very much!

 "getattr(obj, attrname)" works fine as temporary solution

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2787#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2787: History state after commit

[sqlalchemy <mi...@zz...>]

#2787: History state after commit
------------------------------+--------------------------------
      Reporter:  harutune     |      Owner:  zzzeek
          Type:  defect       |     Status:  new
      Priority:  high         |  Milestone:  0.9.0
     Component:  orm          |   Severity:  major - 1-3 hours
    Resolution:               |   Keywords:  history attributes
Progress State:  in progress  |
------------------------------+--------------------------------
Changes (by zzzeek):

 * priority:  medium => high
 * status_field:  awaiting triage => in progress
 * severity:  no triage selected yet => major - 1-3 hours
 * milestone:   => 0.9.0


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2787#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2787: History state after commit

[sqlalchemy <mi...@zz...>]

#2787: History state after commit
----------------------------------+------------------------------------
      Reporter:  harutune         |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  orm              |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:  history attributes
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 well the value there is expired after a commit, to get it back would
 normally be by refreshing from the database (i.e. if you say `u.name`, it
 will load it).

 The history functions were written first and foremost as the system by
 which the ORM does what it needs to do in order to flush changes.   At a
 certain point, we began publishing these functions for general use, as
 they are very useful for lots of things, but a lot of behaviors that are
 by design such as this one don't apply so well to the outside world where
 more consistent behavior is desirable.   Historically, the functions are
 tailored towards answering the question, "has anything changed?", and if
 not, then we don't care what value is actually there or not.  In
 particular the whole system is designed to minimize database calls as much
 as possible.

 So it is a bug in terms of the public API and it is by design in terms of
 the internals.  However, there is a system by which whether or not it
 should load from the database is determined, and that's the "passive"
 flag.  It defaults to PASSIVE_OFF, which means, "go out to the database
 and everything else, it's fine".  So here we can make that change using
 the attached patch.  But also there's a bit of cleanup still needed in
 terms of some of the return codes used by the system internally, i.e.
 NEVER_SET vs. NO_VALUE vs. PASSIVE_NO_RESULT, these could probably use
 another pass.

 For the time being, just say "getattr(obj, attrname)" before you call
 get_history(), as I want further changes to the attribute system to be for
 0.9.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2787#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2787: History state after commit

[sqlalchemy <mi...@zz...>]

#2787: History state after commit
--------------------------------+-----------------------------------------
 Reporter:  harutune            |           Owner:  zzzeek
     Type:  defect              |          Status:  new
 Priority:  medium              |       Milestone:
Component:  orm                 |        Severity:  no triage selected yet
 Keywords:  history attributes  |  Progress State:  awaiting triage
--------------------------------+-----------------------------------------
 We are doing some stuff with history and have a little problem.

 After commit, history has been reseted to empty state: there no value in
 `unchanged` and after attribute is changed there is no value in `deleted`.

 Probably, it is a bug. If it is correct behaviour, how is it expained?

 Both on 0.8.2 and dev versions. Here is a test case.

 {{{
 class HistoryTest(_fixtures.FixtureTest):
     run_inserts = None

     def test_commit_history(self):
         from sqlalchemy.orm.attributes import get_history, History

         User, users = self.classes.User, self.tables.users

         m2 = sa.MetaData()
         users_unbound = users.tometadata(m2)
         mapper(User, users_unbound)

         sess = Session(binds={User: self.metadata.bind})
         u = User(id=1, name='daniel')
         sess.add(u)
         print get_history(u, 'name')
         assert get_history(u, 'name') ==\
                          History(['daniel'], (), ())

         sess.commit()
         print get_history(u, 'name')
         assert get_history(u, 'name') == \
                          History((), ['daniel'], ())
                          # fails: History((), (), ())

         u.name = 'peter'
         print get_history(u, 'name')
         assert get_history(u, 'name') == \
                          History(['peter'], (), ['daniel'])
                          # fails: History(['peter'], (), ())

 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2787>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2786: deferred ORM event registration flags sent incorrectly

[sqlalchemy <mi...@zz...>]

#2786: deferred ORM event registration flags sent incorrectly
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  highest           |  Milestone:  0.8.xx
     Component:  orm               |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  in progress => completed/closed


Comment:

 r90d992f2da1edb8ddfff3fd33d69c6ba7307d2a0 0.8

 r9c6e45ff0157cdd4139cde master

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2786#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2786: deferred ORM event registration flags sent incorrectly

[sqlalchemy <mi...@zz...>]

#2786: deferred ORM event registration flags sent incorrectly
---------------------+------------------------------------
 Reporter:  zzzeek   |           Owner:  zzzeek
     Type:  defect   |          Status:  new
 Priority:  highest  |       Milestone:  0.8.xx
Component:  orm      |        Severity:  major - 1-3 hours
 Keywords:           |  Progress State:  in progress
---------------------+------------------------------------
 the attached patch fixes the coding error but then introduces failures.
 workarounds for the failures are present but these need to be more
 carefully reviewed before committing.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2786>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2785: Array index in postgres ARRAy

[sqlalchemy <mi...@zz...>]

#2785: Array index in postgres ARRAy
------------------------------+------------------------------------
      Reporter:  aterentev    |      Owner:  zzzeek
          Type:  enhancement  |     Status:  new
      Priority:  medium       |  Milestone:  0.8.xx
     Component:  postgres     |   Severity:  no triage selected yet
    Resolution:               |   Keywords:
Progress State:  in queue     |
------------------------------+------------------------------------

Comment (by zzzeek):

 I think we'd want to make the zero index adjustment against literal Python
 values only, not in SQL.   like if someone said
 `table.c.somecolumn[someother_table.c.column]`, assume
 `someother_table.c.column` is one-based.   Though I think there's lots of
 potentially untenable situations here if someone really makes heavy use of
 hybrid behavior in conjunction with array indexing, ultimately in such a
 situation they may have to build their own comparators to work things out
 as needed.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2785#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2785: Array index in postgres ARRAy

[sqlalchemy <mi...@zz...>]

#2785: Array index in postgres ARRAy
------------------------------+------------------------------------
      Reporter:  aterentev    |      Owner:  zzzeek
          Type:  enhancement  |     Status:  new
      Priority:  medium       |  Milestone:  0.8.xx
     Component:  postgres     |   Severity:  no triage selected yet
    Resolution:               |   Keywords:
Progress State:  in queue     |
------------------------------+------------------------------------
Changes (by zzzeek):

 * priority:  low => medium
 * status_field:  awaiting triage => in queue
 * component:  cextensions => postgres
 * milestone:   => 0.8.xx


Comment:

 yeah especially in terms of SQLAlchemy hybrid attributes.   But we can't
 make this a default change, it has to be a flag.  Can you work up a pull
 request for a feature like this?

 {{{
 #!python
 Column('data', ARRAY(Integer, zero_indexed=True))
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2785#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2785: Array index in postgres ARRAy

[sqlalchemy <mi...@zz...>]

#2785: Array index in postgres ARRAy
-------------------------+-----------------------------------------
 Reporter:  aterentev    |           Owner:  zzzeek
     Type:  enhancement  |          Status:  new
 Priority:  low          |       Milestone:
Component:  cextensions  |        Severity:  no triage selected yet
 Keywords:               |  Progress State:  awaiting triage
-------------------------+-----------------------------------------
 Hi.

 When I work with SQLAlchemy and PostgreSQL I find interesting and
 unobvious nuance:

 When using item of array in filter or order_by there are need to use
 indexes starts from 1 (there are no index 0 in pestgres ARRAY)
 But, for getting value or values and use it there are need to use indexes
 starts from zero.


 May be would be better change logic of __getitem__ method of
 sqlalchemy.dialects.postgresql.ARRAY for use one standart of indexes in
 all situations.

 Regards,
 Alexey Terentev

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2785>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2784: Incorrect quoting of the column names during creation of the constraints

[sqlalchemy <mi...@zz...>]

#2784: Incorrect quoting of the column names during creation of the constraints
-----------------------------------+----------------------------------
      Reporter:  adam.markiewicz   |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.8.xx
     Component:  sql               |   Severity:  minor - half an hour
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * component:  engine => sql
 * severity:  no triage selected yet => minor - half an hour
 * status_field:  awaiting triage => completed/closed


Comment:

 the "ix_" names are only a default, you can make specific names using
 Index().   The quote flag isn't supported for the Index name right now but
 the main rationale for the quote flag at the moment is to get around
 reserved words not in SQLAlchemy dialects.  If "boolq" is a reserved word
 in DB2 you should send the ibm_db_sa folks a bug report to add it to the
 reserved word list in that dialect.

 check constraint quoting issue:

 6f265a4e6555a6040db1a6dc566825c0ac263fc7 0.7

 436ba1601d33de048a17e39a14856409c4e9c3b7 0.8

 0a54a4a4b0897bb8eaaf7a7857fb54924ccbd7ef 0.9

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2784#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2784: Incorrect quoting of the column names during creation of the constraints

[sqlalchemy <mi...@zz...>]

#2784: Incorrect quoting of the column names during creation of the constraints
-----------------------------+-----------------------------------------
 Reporter:  adam.markiewicz  |           Owner:  zzzeek
     Type:  defect           |          Status:  new
 Priority:  medium           |       Milestone:  0.8.xx
Component:  engine           |        Severity:  no triage selected yet
 Keywords:                   |  Progress State:  awaiting triage
-----------------------------+-----------------------------------------
 Hello,

 I've experienced that in DB2 and verified for SQLite and MySQL.
 The problem I have is:
 Names with all lower-case letters are considered case-insensitive.
 DB2 is dumb and stores those internally in all upper-case. (!!!)
 Case-sensitive names are supposed to be quoted inside SQL statements.
 In my project I have columns like: 'firstUser' and 'address'.
 So the first one is considered case-sensitive, the second case-
 insensitive.
 Having lots of unexpected problems I wanted to remain consistent and
 enforce quoting of all names.
 I've found in the SQL Alchemy documentation that I can do that with the
 appropriate Table and Column argument named ''quote''.
 The problem is that it affects quoting of the names for specifying the
 columns themselves, not while specifying constraints on them - at least
 not on all types.

 Example:

 {{{

 users = Table('users', metadata,
     Column('boolq', Boolean, nullable=False, unique=True, quote=True),
     Column('bool', Boolean, nullable=False, unique=True),
     Column('boolC', Boolean, nullable=False, unique=True),
     quote=True
 )


 CREATE TABLE "users" (
         "boolq" BOOLEAN NOT NULL,
         bool BOOLEAN NOT NULL,
         "boolC" BOOLEAN NOT NULL,
         UNIQUE ("boolq"),
         CHECK (boolq IN (0, 1)),
         UNIQUE (bool),
         CHECK (bool IN (0, 1)),
         UNIQUE ("boolC"),
         CHECK ("boolC" IN (0, 1))
 )

 2013-07-17 13:17:21,328 INFO sqlalchemy.engine.base.Engine ()
 2013-07-17 13:17:21,358 INFO sqlalchemy.engine.base.Engine COMMIT
 2013-07-17 13:17:21,358 INFO sqlalchemy.engine.base.Engine CREATE UNIQUE
 INDEX ix_users_boolq ON "users" ("boolq")
 2013-07-17 13:17:21,358 INFO sqlalchemy.engine.base.Engine ()
 2013-07-17 13:17:21,390 INFO sqlalchemy.engine.base.Engine COMMIT
 2013-07-17 13:17:21,390 INFO sqlalchemy.engine.base.Engine CREATE UNIQUE
 INDEX "ix_users_boolC" ON "users" ("boolC")
 2013-07-17 13:17:21,390 INFO sqlalchemy.engine.base.Engine ()
 2013-07-17 13:17:21,437 INFO sqlalchemy.engine.base.Engine COMMIT
 2013-07-17 13:17:21,437 INFO sqlalchemy.engine.base.Engine CREATE UNIQUE
 INDEX ix_users_bool ON "users" (bool)
 2013-07-17 13:17:21,437 INFO sqlalchemy.engine.base.Engine ()
 2013-07-17 13:17:21,467 INFO sqlalchemy.engine.base.Engine COMMIT

 }}}

 In the above case DB2 rejects the command complaining that it cannot apply
 ''CHECK (boolq IN (0, 1))'' to the table ''users'', as the table does not
 contain the column ''BOOLQ''.

 However neither SQLite nor MySQL do complain during the execution,
 although the command generated isn't correct.

 I'm also wondering if the names of the generated indexes should not follow
 the quoting restrictions of the appropriate table and column, so if the
 name 'ix_users_boolq' shouldn't be quoted at least because column boolq
 was quoted and 'ix_users_bool' shouldn't be quoted because the table
 'users' was quoted (and the name of the table would affect all its indexes
 really). But this is not an issue for me at the moment.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2784>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2268: implement removal for SQLAlchemy events

[sqlalchemy <mi...@zz...>]

#2268: implement removal for SQLAlchemy events
---------------------------+---------------------------------------
      Reporter:  guest     |      Owner:  zzzeek
          Type:  task      |     Status:  new
      Priority:  medium    |  Milestone:  0.9.0
     Component:  engine    |   Severity:  very major - up to 2 days
    Resolution:            |   Keywords:
Progress State:  in queue  |
---------------------------+---------------------------------------
Changes (by zzzeek):

 * milestone:  0.x.xx => 0.9.0


Comment:

 a possible technique here could be that a target event listening function
 receives a collection (or some weak referencing association) that can
 point it to every ListenerCollection etc. which it is a part of, including
 some callable that can remove this event from that collection, taking into
 account whatever wrappers have been applied to it.   Any
 ListenerCollection that receives a new event would make sure this
 registration takes place.  If done consistently, this should account for
 all the many ways that a listener function gets assigned to many places,
 across subclasses, copies of dispatchers, etc. and not expose any of that
 to the removal process.

 tentative 0.9 assignment, we'll see if we get to it.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2268#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2783: rendering of aliased CTE

[sqlalchemy <mi...@zz...>]

#2783: rendering of aliased CTE
------------------------------+----------------------------------
      Reporter:  zzzeek       |      Owner:  zzzeek
          Type:  defect       |     Status:  new
      Priority:  high         |  Milestone:  0.8.xx
     Component:  sql          |   Severity:  minor - half an hour
    Resolution:               |   Keywords:
Progress State:  needs tests  |
------------------------------+----------------------------------
Changes (by zzzeek):

 * severity:  major - 1-3 hours => minor - half an hour
 * status_field:  in queue => needs tests


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2783#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2783: rendering of aliased CTE

[sqlalchemy <mi...@zz...>]

#2783: rendering of aliased CTE
--------------------+------------------------------------
 Reporter:  zzzeek  |           Owner:  zzzeek
     Type:  defect  |          Status:  new
 Priority:  high    |       Milestone:  0.8.xx
Component:  sql     |        Severity:  major - 1-3 hours
 Keywords:          |  Progress State:  in queue
--------------------+------------------------------------
 {{{
 #!python
 from sqlalchemy import *
 from sqlalchemy.orm import *
 from sqlalchemy.ext.declarative import declarative_base

 Base = declarative_base()

 class Semester(Base):
     __tablename__ = 'semesters'

     id = Column(Integer, primary_key=True)
     start_date = Column(Date)
     end_date = Column(Date)

 class Student(Base):
     __tablename__ = 'students'

     id = Column(Integer, primary_key=True)
     start_date = Column(Date)
     n_weeks = Column(Integer)


 S = Student.__table__.alias("S")
 s1 = select([
                 Semester.id.label("semester_id"),
                 func.generate_series(
                         Semester.start_date,
                         Semester.end_date, "1 day").label("day_date")
             ]).alias("day_series")

 semester_days = select([
             s1.c.semester_id,
             func.row_number().over().label("day_number"),
             s1.c.day_date]).order_by(s1.c.day_date).cte("semester_days")

 # if you alias this, then the CTE doesn't render
 SD_start = semester_days #.alias("SD_start")
 SD_end = semester_days.alias("SD_end")


 s2 = select([
             S.c.id.label("student_id"),
             S.c.start_date,
             SD_start.c.semester_id.label("start_semester_id"),
             S.c.n_weeks,
             SD_end.c.day_date.label("end_date"),
             SD_end.c.semester_id.label("end_semester_id")
         ]).select_from(
             S.join(SD_start, S.c.start_date == SD_start.c.day_date).
             join(SD_end, SD_end.c.day_number == SD_start.c.day_number + (7
 * S.c.n_weeks))
         ).order_by(S.c.start_date)

 print s2
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2783>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2782: add the setuptools hack for setup.py test

[sqlalchemy <mi...@zz...>]

#2782: add the setuptools hack for setup.py test
--------------------+---------------------------------------
 Reporter:  zzzeek  |           Owner:  zzzeek
     Type:  defect  |          Status:  new
 Priority:  medium  |       Milestone:  0.8.xx
Component:  tests   |        Severity:  minor - half an hour
 Keywords:          |  Progress State:  in queue
--------------------+---------------------------------------
 master, 0.8, 0.7:

 {{{
 # Hack to prevent "TypeError: 'NoneType' object is not callable" error
 # in multiprocessing/util.py _exit_function when running `python
 # setup.py test` (see
 # http://www.eby-sarna.com/pipermail/peak/2010-May/003357.html)
 try:
     import multiprocessing
 except ImportError:
     pass
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2782>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2616: Confusing wording on yield_per

[sqlalchemy <mi...@zz...>]

#2616: Confusing wording on yield_per
-----------------------------------+----------------------------------
      Reporter:  G2P               |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.8.xx
     Component:  documentation     |   Severity:  minor - half an hour
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  in progress => completed/closed


Comment:

 this is in master/0.8/0.7: 0d4b769d6aed2979  7da90f41b269f7b4
 bb290b46a65d51f thanks !

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2616#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2616: Confusing wording on yield_per

[sqlalchemy <mi...@zz...>]

#2616: Confusing wording on yield_per
--------------------------------+----------------------------------
      Reporter:  G2P            |      Owner:  zzzeek
          Type:  defect         |     Status:  new
      Priority:  low            |  Milestone:  0.8.xx
     Component:  documentation  |   Severity:  minor - half an hour
    Resolution:                 |   Keywords:
Progress State:  in progress    |
--------------------------------+----------------------------------

Comment (by iElectric):

 Made a pull request: https://github.com/zzzeek/sqlalchemy/pull/17

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2616#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2778: per-attribute callables due to options, possible reorg to remove performance overhead

[sqlalchemy <mi...@zz...>]

#2778: per-attribute callables due to options, possible reorg to remove
performance overhead
-----------------------------------+----------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.8.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * milestone:  0.9.0 => 0.8.xx
 * resolution:   => fixed
 * severity:  very major - up to 2 days => minor - half an hour
 * status_field:  in queue => completed/closed


Comment:

 So with some profiling added, previously defer() would bump the callcounts
 up significantly, it now uses fewer calls than that of loading the column.
 the change here isn't that dramatic, just not bundling the "state" with
 those callables (so we only need create one per col, not per col per row)
 and producing the closure after retrieving the `AttributeImpl`, not
 before.

 r731a4daf63dc0fdb784d195e89c5f357420657fb 0.8

 r5b65af098324a1852c1ca885f5c79b68cd2733c5 master

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2778#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2780: str() call in make_proxy can get in the way w/ dialect specific operators

[sqlalchemy <mi...@zz...>]

#2780: str() call in make_proxy can get in the way w/ dialect specific operators
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  highest           |  Milestone:  0.8.xx
     Component:  sql               |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  in progress => completed/closed


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2780#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2781: sqlite datetime types - totally broken

[sqlalchemy <mi...@zz...>]

#2781: sqlite datetime types - totally broken
-----------------------------------+----------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  highest           |  Milestone:  0.8.xx
     Component:  sql               |   Severity:  minor - half an hour
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * severity:  major - 1-3 hours => minor - half an hour
 * status_field:  in progress => completed/closed


Comment:

 r2edc13a6b82b264beba0b20f96f252d7b7a96f28 0.8

 r63488b2d1ea47d30db23e3e5659917fcb4 master

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2781#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2781: sqlite datetime types - totally broken

[sqlalchemy <mi...@zz...>]

#2781: sqlite datetime types - totally broken
---------------------+------------------------------------
 Reporter:  zzzeek   |           Owner:  zzzeek
     Type:  defect   |          Status:  new
 Priority:  highest  |       Milestone:  0.8.xx
Component:  sql      |        Severity:  major - 1-3 hours
 Keywords:           |  Progress State:  in progress
---------------------+------------------------------------
 adapt() doesnt work and these types have never worked with custom reg or
 storage format

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2781>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2780: str() call in make_proxy can get in the way w/ dialect specific operators

[sqlalchemy <mi...@zz...>]

#2780: str() call in make_proxy can get in the way w/ dialect specific operators
------------------------------+-------------------------------
      Reporter:  zzzeek       |      Owner:  zzzeek
          Type:  defect       |     Status:  new
      Priority:  highest      |  Milestone:  0.8.xx
     Component:  sql          |   Severity:  major - 1-3 hours
    Resolution:               |   Keywords:
Progress State:  in progress  |
------------------------------+-------------------------------

Comment (by zzzeek):

 since this is a lesser-occurring codepath, it's actually just catching the
 exception and falling back to `anon_label`.   A new exception class
 `UnsupportedCompilationError` is also added which catches operators as
 well as unsupported visit names.

 r574dba8e61f5f86e0c809c0c15640379a8847533 0.8

 r0ca7b53b4235c2fbabfbb6a4e2df2f master

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2780#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2780: str() call in make_proxy can get in the way w/ dialect specific operators

[sqlalchemy <mi...@zz...>]

#2780: str() call in make_proxy can get in the way w/ dialect specific operators
------------------------------+-------------------------------
      Reporter:  zzzeek       |      Owner:  zzzeek
          Type:  defect       |     Status:  new
      Priority:  highest      |  Milestone:  0.8.xx
     Component:  sql          |   Severity:  major - 1-3 hours
    Resolution:               |   Keywords:
Progress State:  in progress  |
------------------------------+-------------------------------

Comment (by zzzeek):

 My guess as to how the original poster only uses the index operator in
 order_by and still sees this is because the eager load is trying to stick
 that column in the columns clause so that it can order the enclosing query
 the same way.   so for our purposes the bug is just this:

 {{{
 from sqlalchemy.dialects.postgresql import ARRAY

 from sqlalchemy import Integer
 from sqlalchemy.sql import table, column, select

 t = table('t', column('x', ARRAY(Integer)))

 s = select([t, t.c.x[5]])

 s.corresponding_column(t.c.x)
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2780#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python