2. no synonym parameter, schema = 'AINV_OWNER' on Table(...)
Results in the error: Could not determine join condition between
parent/child tables... I had expected this to work but it seems that
for some reason SQLA doesn't see the constraint info on tables in
another user's schema. Is
Hi everyone!
I have a simple Invoices class with a Number attribute that has to
be filled in by the application when the user saves an invoice. There
are some constraints:
1) the application is a (thin) client-server one, so whatever
determines the number must look out for collisions
2) Invoices
Hello
Sqlalchemy appears to be aliasing each column in a SELECT statement as
a concatenation of the schema, table name and column name. The
resulting alias exceeds DB2's 30 character limit for a column.
For example:
If the name of the schema was 'myshemaname', the table was called
Hello
Sqlalchemy appears to be aliasing each column in a SELECT statement as
a concatenation of the schema, table name and column name. The
resulting alias exceeds DB2's 30 character limit for a column.
For example:
If the name of the schema was 'myshemaname', the table was called
Beeno wrote:
Hello
Sqlalchemy appears to be aliasing each column in a SELECT statement as
a concatenation of the schema, table name and column name. The
resulting alias exceeds DB2's 30 character limit for a column.
For example:
If the name of the schema was 'myshemaname', the table was
Joril wrote:
On 24 Giu, 14:27, Joril jor...@gmail.com wrote:
Is this a decent solution?
Someone suggested me to use a callable as the default parameter on
the Column definition instead.. I'll try it right away. Anyway I'd
still like to know about my second question.. :)
whats the second
On 24 Giu, 16:28, Michael Bayer mike...@zzzcomputing.com wrote:
whats the second question ? is this expected? yes. TypeEngine objects
don't have anything to do with default value generation.
I see, thanks!
--~--~-~--~~~---~--~~
You received this message
Hi All,
I'm wondering what the common idiom is for unit testing w.r.t. data and
transactions...
So, coming from my ZODB background, in unit tests we usually:
- set up the objects required
- run the code to be tested (which might change, add or delete objects)
- abort the current transaction
