at 8:17 PM, Mike Bayer mike...@zzzcomputing.com
wrote:
On 6/25/15 2:08 PM, Kevin Qiu wrote:
In the SQLalchemy documentation
http://docs.sqlalchemy.org/en/latest/orm/inheritance.html#basic-control-of-which-tables-are-queried,
it states
It is standard practice that the same column is used
In the SQLalchemy documentation
http://docs.sqlalchemy.org/en/latest/orm/inheritance.html#basic-control-of-which-tables-are-queried,
it states
It is standard practice that the same column is used for both the role of
primary key as well as foreign key to the parent table, and that the
...@zzzcomputing.com
wrote:
On 6/21/15 1:46 PM, Kevin Qiu wrote:
It's a test db, there's only one record being added to the table. And I
ensure that with a assertIn() test and it passes.
The original code was:
class Application(mydb.Model):
__tablename__ = 'APPLICATION'
app_id = mydb.Column
I create a unit test that add new ProjApp object to the database, but the
returned object shows it is not the same object inserted, I don't follow
why it's like this because I have others tests on inserting a row to a
different table, and returned shows the same row object.
Test result:
/15 12:45 PM, Kevin Qiu wrote:
I create a unit test that add new ProjApp object to the database, but
the returned object shows it is not the same object inserted, I don't
follow why it's like this because I have others tests on inserting a row to
a different table, and returned shows
I try to define composite index on last_name, first_name on
flask-sqlalchemy, the error says NameError: name 'Index' is not defined
Code:
class Student(mydb.Model):
__tablename__ = 'STUDENT'
__table_args__ = (Index('SearchNameIndices', last_name, first_name), )
study_no =
Error: SAWarning: Warning: relationship 'staff_obj' on mapper
'Mapper|ProjectApp|PROJECT_APP' supersedes the same relationship on
inherited mapper 'Mapper|Application|APPLICATION'; this can cause
dependency issues during flush
self._check_conflicts()
Application is a parent class which can't
In my example, the extra join was brought in by the relationship
`Thing.user`. Because the query was on Thing, and the filtering criteria is
on `User`, which, if I'm not mistaken, causes sqlalchemy to consult the
mapper and bring in the relationship between `Thing` and `User`.
Anyway, I think
