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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2724: Unclear documentation for join

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

#2724: Unclear documentation for join
-----------------------------------+------------------------------------
      Reporter:  dwt               |      Owner:  zzzeek
          Type:  enhancement       |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  documentation     |   Severity:  no triage selected yet
    Resolution:  duplicate         |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------

Comment (by rbu):

 Haha, that would be amazing. We had been pairing on the issue, and failed
 to agree who would report it.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2723: SQLAlchemy relationships on inherited attributes fail

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

#2723: SQLAlchemy relationships on inherited attributes fail
-------------------------------------+-------------------------------------
      Reporter:  mitchellrj          |      Owner:  zzzeek
          Type:  defect              |     Status:  new
      Priority:  medium              |  Milestone:
     Component:  orm                 |   Severity:  no triage selected yet
    Resolution:                      |   Keywords:  relationship inherited
Progress State:  needs questions     |  inheritance foreign key
  answered                           |
-------------------------------------+-------------------------------------
Changes (by zzzeek):

 * status_field:  awaiting triage => needs questions answered


Comment:

 can you fix up your test please?   I'm not sure what "A" is, or "People",
 I've created a simple test as below and there's no issue:

 {{{
 from sqlalchemy import *
 from sqlalchemy.orm import *
 from sqlalchemy.ext.declarative import declarative_base

 Base = declarative_base()

 class Person(Base):
     __tablename__ = 'people'

     id = Column(Integer, primary_key=True)
     type = Column(Enum('staff', 'student'))
     username = Column(String)

     __mapper_args__ = {
         'polymorphic_on': type
     }

 class Staff(Person):
     __tablename__ = 'staff'

     id = Column(Integer, ForeignKey(Person.id), primary_key=True)

     __mapper_args__ = {
         'polymorphic_identity': 'staff'
     }

 class Department(Base):
     __tablename__ = 'departments'

     id = Column(Integer, primary_key=True)
     head_username = Column(String, ForeignKey(Staff.username))

     head = relationship(Staff)

 configure_mappers()
 }}}

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2724: Unclear documentation for join

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

#2724: Unclear documentation for join
-----------------------------------+------------------------------------
      Reporter:  dwt               |      Owner:  zzzeek
          Type:  enhancement       |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  documentation     |   Severity:  no triage selected yet
    Resolution:  duplicate         |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => duplicate
 * status_field:  awaiting triage => completed/closed


Comment:

 oh are you guys working together?  that would explain what would otherwise
 be an amazing coincidence.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2722: clarify what should happen with query(A).select_from(A).join(B.a) (was: Unexpected JOIN order (left / right))

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

#2722: clarify what should happen with query(A).select_from(A).join(B.a)
--------------------------------+-------------------------------
      Reporter:  rbu            |      Owner:  zzzeek
          Type:  defect         |     Status:  new
      Priority:  medium         |  Milestone:  0.8.xx
     Component:  documentation  |   Severity:  major - 1-3 hours
    Resolution:                 |   Keywords:
Progress State:  in queue       |
--------------------------------+-------------------------------
Changes (by zzzeek):

 * component:  cextensions => documentation
 * milestone:   => 0.8.xx
 * severity:  no triage selected yet => major - 1-3 hours
 * status_field:  awaiting triage => in queue


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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2722: Unexpected JOIN order (left / right)

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

#2722: Unexpected JOIN order (left / right)
----------------------------------+------------------------------------
      Reporter:  rbu              |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  cextensions      |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 it really falls under the realm of undefined behavior at the moment.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2722: Unexpected JOIN order (left / right)

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

#2722: Unexpected JOIN order (left / right)
----------------------------------+------------------------------------
      Reporter:  rbu              |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  cextensions      |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 yeah that's amazing how issue reports come in pairs like that right?  this
 behavior has been the same for years.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2722: Unexpected JOIN order (left / right)

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

#2722: Unexpected JOIN order (left / right)
----------------------------------+------------------------------------
      Reporter:  rbu              |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  cextensions      |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by rbu):

 duplicate report on our side, see also #2724

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2724: Unclear documentation for join

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

#2724: Unclear documentation for join
----------------------------------+------------------------------------
      Reporter:  dwt              |      Owner:  zzzeek
          Type:  enhancement      |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  documentation    |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by rbu):

 duplicate report on our side, see also #2722

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

[Sqlalchemy-tickets] [sqlalchemy] #2724: Unclear documentation for join

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

#2724: Unclear documentation for join
---------------------------+-----------------------------------------
 Reporter:  dwt            |           Owner:  zzzeek
     Type:  enhancement    |          Status:  new
 Priority:  medium         |       Milestone:
Component:  documentation  |        Severity:  no triage selected yet
 Keywords:                 |  Progress State:  awaiting triage
---------------------------+-----------------------------------------
 I've found that the documentation for join at
 http://docs.sqlalchemy.org/en/rel_0_8/orm/query.html#sqlalchemy.orm.query.Query.join
 was lacking the information that the direction of the join, i.e. what is
 the left side and what is the righthand side of a join can be decided by
 the way you write the argument to the join call.

 So it makes a difference if you write
 {{{DBSession.query(User).join(Track.user)}}} - that will {{{select * from
 Track join User}}} or if you write
 {{{DBSession.query(User).join(User.tracks)}}} which will {{{select * from
 User join Track}}}.

 As far as my understanding of sql is that shouldn't make a difference, but
 when you switch from join to {{{outerjoin()}}}, suddenly this distinction
 becomes very important as it defines the lefthand side of the left outer
 join and someting you cannot override even with {{{select_from()}}}.

 And that is what cost us quite some time today to figure out - so a
 clearer mention of this in the documentation would be really helpfull.

 Hope this clarifies what I mean,

 Best Regards,
 Martin

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

[Sqlalchemy-tickets] [sqlalchemy] #2723: SQLAlchemy relationships on inherited attributes fail

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

#2723: SQLAlchemy relationships on inherited attributes fail
-------------------------------------+-------------------------------------
 Reporter:  mitchellrj               |           Owner:  zzzeek
     Type:  defect                   |          Status:  new
 Priority:  medium                   |       Milestone:
Component:  orm                      |        Severity:  no triage selected
 Keywords:  relationship inherited   |  yet
  inheritance foreign key            |  Progress State:  awaiting triage
-------------------------------------+-------------------------------------
 In the given example below, I get the following error while mappers are
 being configured:
 {{{
         if nrte.table_name == b.name:
     AttributeError: 'Join' object has no attribute 'name'
 }}}
 This appears to be because the foreign key is a property of the parent
 model, rather than the target model. Please ignore that this could be
 avoided by using the `id` column as foreign key in the example, as this is
 not possible in my 'real' case.
 {{{
     class Person(Base):
         __tablename__ = 'people'

         id = Column(Integer, primary_key=True)
         type = Column(Enum('staff', 'student'))
         username = Column(String)

         __mapper_args__ = {
             'polymorphic_on': type
         }

     class Staff(A):
         __tablename__ = 'staff'

         id = Column(Integer, ForeignKey(People.id), primary_key=True)

         __mapper_args__ = {
             'polymorphic_identity': 'staff'
         }

     class Department(Base):
         __tablename__ = 'departments'

         id = Column(Integer, primary_key=True)
         head_username = Column(String, ForeignKey(Staff.username))

         head = relationship(Staff)
 }}}

 This is in SQLAlchemy 0.8.0

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

[Sqlalchemy-tickets] [sqlalchemy] #2722: Unexpected JOIN order (left / right)

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

#2722: Unexpected JOIN order (left / right)
-------------------------+-----------------------------------------
 Reporter:  rbu          |           Owner:  zzzeek
     Type:  defect       |          Status:  new
 Priority:  medium       |       Milestone:
Component:  cextensions  |        Severity:  no triage selected yet
 Keywords:               |  Progress State:  awaiting triage
-------------------------+-----------------------------------------
 We had quite a hard time figuring out the JOIN order as generated by a
 query(A).join(B) statement. All examples in the documentation have A as
 left and B as right side. Apparently though, when giving an explicit
 criterion as query(A).join(B.a), B will be the left side even when adding
 a select_from.

 Details:

 {{{
 # surprising
 >>> print DBSession.query(User.id).outerjoin(Track.user)
 SELECT user.id AS user_id
 FROM track LEFT OUTER JOIN user ON user.id = track.user_id

 # bug?
 >>> print DBSession.query(User.id).select_from(User).outerjoin(Track.user)
 SELECT user.iduser AS user_id
 FROM track LEFT OUTER JOIN user ON user.id = track.user_id

 # expected
 >>> print DBSession.query(User.id).outerjoin(User.tracks)
 SELECT user.iduser AS user_id
 FROM user LEFT OUTER JOIN track ON user.id = track.user_id
 }}}

 This magic ordering based on the explicit criterion given should be
 covered in the documentation, but we did not find such note.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by claudiofreire):

 Alright, virtualenv in place,

 Unpached (no cinstrumented):

 {{{
 (env)claudiofreire@klaumpp:~/src/SQLAlchemy-0.8.1>
 PYTHONPATH=$(pwd)/build/lib.linux-x86_64-2.7/ python
 test/perf/orm2010read.py
 /home/claudiofreire/src/SQLAlchemy-0.8.1/build/lib.linux-
 x86_64-2.7/sqlalchemy/types.py:307: SAWarning: Dialect sqlite+pysqlite
 does *not* support Decimal objects natively, and SQLAlchemy must convert
 from floating point - rounding errors and other issues may occur. Please
 consider storing Decimal numbers as strings or integers on this platform
 for lossless storage.
   d[coltype] = rp = d['impl'].result_processor(dialect, coltype)
 SQLA Version: 0.8.1
 Total calls 706284
 Total cpu seconds: 1.94
 Total execute calls: 101
 Total executemany calls: 0
 sh: runsnake: command not found
 }}}

 Patched (with cinstrumented):
 {{{
 (env)claudiofreire@klaumpp:~/src/SQLAlchemy-0.8.1>
 PYTHONPATH=$(pwd)/build/lib.linux-x86_64-2.7/ python
 test/perf/orm2010read.py
 /home/claudiofreire/src/SQLAlchemy-0.8.1/build/lib.linux-
 x86_64-2.7/sqlalchemy/types.py:307: SAWarning: Dialect sqlite+pysqlite
 does *not* support Decimal objects natively, and SQLAlchemy must convert
 from floating point - rounding errors and other issues may occur. Please
 consider storing Decimal numbers as strings or integers on this platform
 for lossless storage.
   d[coltype] = rp = d['impl'].result_processor(dialect, coltype)
 SQLA Version: 0.8.1
 Total calls 646370
 Total cpu seconds: 1.69
 Total execute calls: 101
 Total executemany calls: 0
 sh: runsnake: command not found
 }}}

 Will attach orm2010read.py, with emphasis on read-only stuff.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by claudiofreire):

 Oh... I know... I have cinstrumented installed in python, if it's not
 there it loads it from /usr/local...

 I'll have to build a virtualenv.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by claudiofreire):

 Then I'm running the tests the wrong way...

 I mess or restore ./build/lib.blah/sqlalchemy/cinstrumented.so and run
 ./sqla_nose.py test.aaa_profiling.test_orm or python
 ./test/perf/orm2010.py

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by zzzeek):

 using declarative vs. mapper() has no effect on how columns are ultimately
 mapped.   If the table has a column ".id", it is instrumented in the same
 way whether or not declarative is used.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by claudiofreire):

 Um... I've been having trouble reproducing the function call excess
 problem with test_orm, and I noticed it doesn't use declarative, so only
 relationships use instrumented attributes.

 However, when using declarative, even basic columns do.

 So, I guess what's needed here is a test using declarative. Is orm_2010
 that? I can't find it in test/aaa_profiling...

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases

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

#2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases
-------------------------------------------+-------------------------------
      Reporter:  kashif                    |      Owner:
          Type:  defect                    |     Status:  new
      Priority:  high                      |  Milestone:  0.8.xx
     Component:  mysql                     |   Severity:  minor - half an
    Resolution:                            |  hour
Progress State:  needs questions answered  |   Keywords:  mysql deferrable
-------------------------------------------+-------------------------------

Comment (by kashif):

 Actually ATM we're using both mysql and postgres, some environments
 running on mysql and some on postgres. Needed to defer FK checks since
 postgres seems to be more strict and there is no "SET
 FOREIGN_KEY_CHECKS=0;" for postgres. I was loading data into a table
 containing self-referening FKs.

 So when I got everything working with postgres with all tests passing,
 mysql started objecting. For the time being I've worked around that using

     if db.engine.url.drivername.startswith('postgresql'):

 but would be nice if SQLAlchemy could do that :-)

 Thank you for your prompt response. Love SQLA and would love it to be even
 better :-)

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases

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

#2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases
-------------------------------------------+-------------------------------
      Reporter:  kashif                    |      Owner:
          Type:  defect                    |     Status:  new
      Priority:  high                      |  Milestone:  0.8.xx
     Component:  mysql                     |   Severity:  minor - half an
    Resolution:                            |  hour
Progress State:  needs questions answered  |   Keywords:  mysql deferrable
-------------------------------------------+-------------------------------
Changes (by zzzeek):

 * milestone:   => 0.8.xx
 * severity:  no triage selected yet => minor - half an hour
 * status_field:  awaiting triage => needs questions answered


Comment:

 OK, though that's an odd case that you need your FK's to be DEFERRABLE,
 yet your app runs on MySQL (using MyISAM or InnoDB) ?   That's kind of why
 the keyword isn't skipped right now - it assumes if you put "DEFERRABLE",
 you actually need that functionality and if the DB doesn't support it, an
 error should be raised.

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

[Sqlalchemy-tickets] [sqlalchemy] #2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases

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

#2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases
-----------------------------------------+------------------------------
      Reporter:  kashif                  |       Type:  defect
        Status:  new                     |   Priority:  high
     Milestone:                          |  Component:  mysql
      Severity:  no triage selected yet  |   Keywords:  mysql deferrable
Progress State:  awaiting triage         |
-----------------------------------------+------------------------------
 Foreign Key constraints in MySQL don't support the DEFERRABLE
 clause/keyword, however if a FK constraint contains deferrable=True,
 DEFERRABLE keyword is emitted in the table create DDL. This should not be
 the case since table creation fails for table containing FKs with
 deferrable=True.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by zzzeek):

 so yes, what would be good here would be a test like orm2010.py that has a
 heavy emphasis on attribute access.  orm2010.py is heavy on the
 persistence side, though persistence makes a lot of use of getters too.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by zzzeek):

 "no C extension" means I removed the file "cinstrumented.so" alone, so the
 other C extensions remained in place.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by claudiofreire):

 Is "no C extension" '''no''' extension at all, or just no patch?

 If it's no extension at all, it makes difficult to compare. I also don't
 know about the test's representativeness. It doesn't seem to do much with
 the objects, just fetch them.

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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------
Changes (by zzzeek):

 * cc: klaussfreire@… (added)


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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------
Changes (by zzzeek):

 * owner:  ged => zzzeek


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

Re: [Sqlalchemy-tickets] [sqlalchemy] #2720: new C extensions for attribute accessing

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

#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
      Reporter:  zzzeek            |      Owner:  ged
          Type:  enhancement       |     Status:  new
      Priority:  medium            |  Milestone:  0.9.0
     Component:  cextensions       |   Severity:  very major - up to 2 days
    Resolution:                    |   Keywords:
Progress State:  not decided upon  |
-----------------------------------+---------------------------------------

Comment (by zzzeek):

 Running this against 0.8, only one of the aaa_profiling tests falls out of
 range here.  Here's a summary of most of the ORM related profiling tests.
 The orm_2010.py script has the best savings as it works with a large
 number of objects.  Overall these savings aren't too dramatic.

 {{{
 C extension, test_orm

 Pstats calls: 16991
 Pstats calls: 113793
 Pstats calls: 19165
 Pstats calls: 1190
 Pstats calls: 122
 Pstats calls: 18

 no C extension, test_orm

 Pstats calls: 17987
 Pstats calls: 114819
 Pstats calls: 19165
 Pstats calls: 1190
 Pstats calls: 122
 Pstats calls: 18


 C extension, zoomark_orm:

 Pstats calls: 6140
 Pstats calls: 390
 Pstats calls: 6389
 Pstats calls: 19003
 Pstats calls: 1049
 Pstats calls: 2671

 no C extension: zoomark ORM

 Pstats calls: 6104
 Pstats calls: 390
 Pstats calls: 6397
 Pstats calls: 19024
 Pstats calls: 1049
 Pstats calls: 2668

 C extension, orm_2010.py

 Total calls 4055180
 Total cpu seconds: 4.41
 Total execute calls: 11201
 Total executemany calls: 101

 no C extension, orm_2010.py

 Total calls 4137179
 Total cpu seconds: 4.46
 Total execute calls: 11201
 Total executemany calls: 101
 }}}

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