Thanks! That solved it.
I'm a JOIN newbie, so I didn't realize left join and outer join were the
same thing.
J.
On Monday, August 3, 2015 at 5:08:44 PM UTC+2, Ladislav Lenart wrote:
Hello.
pgAdmin query uses LEFT JOIN whereas SQLAlchemy query uses (inner) JOIN.
Replace
.join(...)
On 3.8.2015 17:24, jurie.horne...@gmail.com wrote:
Thanks! That solved it.
I'm a JOIN newbie, so I didn't realize left join and outer join were the same
thing.
Well, in that case this might be of some use to you...
SQL:
* JOIN is short for INNER JOIN.
* LEFT JOIN is short for LEFT OUTER
I am using Python 2.7, SQLAlchemy 0.9.3, and PostgreSQL 9.4.
This:
session.query(self.db.recording_table.c.id).\
join(self.db.frame_table, self.db.recording_table.c.id ==
self.db.frame_table.c.recording_id).\
group_by(self.db.recording_table.c.id).\
On 8/3/15 6:51 PM, Mike Bayer wrote:
On 8/3/15 4:59 PM, Dirk Makowski wrote:
Hi all,
after upgrading alembic to 0.7.7 and SQLAlchemy to 1.0.8, when I try
to downgrade one step from head, I get the below KeyError. The
allegedly missing key is the revision ID of head. It is correctly
On 8/3/15 4:59 PM, Dirk Makowski wrote:
Hi all,
after upgrading alembic to 0.7.7 and SQLAlchemy to 1.0.8, when I try
to downgrade one step from head, I get the below KeyError. The
allegedly missing key is the revision ID of head. It is correctly
stored in the alembic table, and the file and
On 8/3/15 7:02 PM, Mike Bayer wrote:
On 8/3/15 6:51 PM, Mike Bayer wrote:
On 8/3/15 4:59 PM, Dirk Makowski wrote:
Hi all,
after upgrading alembic to 0.7.7 and SQLAlchemy to 1.0.8, when I try
to downgrade one step from head, I get the below KeyError. The
allegedly missing key is the
I had do revert back to alembic 0.6.7 for the down-migration to work again
(upgraded today from 0.6.6). Please find attached the bare scripts.
On Monday, August 3, 2015 at 11:27:40 PM UTC+2, Michael Bayer wrote:
can you confirm no issue with Alembic 0.7.6?Can you please send along
all
I never used JSON before or know something about it. I will check that.
On 2015-08-03 14:38 Adam Tauno Williams awill...@whitemice.org wrote:
On the contrary - and emphatically - just about every modern RDMBS
supports collection types including lists, sets, multi-sets, and
key-value data.
can you confirm no issue with Alembic 0.7.6?Can you please send
along all of your migration scripts; feel free to erase everything but
the version headers and empty upgrade() / downgrade() functions, I just
need to see the structure you're working with. thanks.
On 8/3/15 4:59 PM, Dirk
On 2015-08-02 19:15 c.bu...@posteo.jp wrote:
But what is about SQLAlchemy? I see nowhere a implementation of a
List() type that encapsulate that VARCHAR-depending converting work?
When implementing this myself. I am not sure if I have to use
TypeDecorator
or
UserDefinedType
as baseclass for
On 2015-08-03 01:17 Pavel S pa...@schon.cz wrote:
You should refer documentation of your RDBMS.
It is sqlite3.
'*func*' is just proxy to any function defined inside RDBMS.
If your RDBMS has function *bla* (e.g. CREATE FUNCTION bla...), then
you can call if from python using *func.bla()*.
You should refer documentation of your RDBMS.
'*func*' is just proxy to any function defined inside RDBMS.
If your RDBMS has function *bla* (e.g. CREATE FUNCTION bla...), then you
can call if from python using *func.bla()*.
Dne neděle 2. srpna 2015 19:12:04 UTC+2 c.b...@posteo.jp napsal(a):
Hello.
pgAdmin query uses LEFT JOIN whereas SQLAlchemy query uses (inner) JOIN. Replace
.join(...) with .outerjoin(...) in your SQLAlchemy query.
HTH,
Ladislav Lenart
On 3.8.2015 16:48, jurie.horne...@gmail.com wrote:
I am using Python 2.7, SQLAlchemy 0.9.3, and PostgreSQL 9.4.
This:
all of those syntaxes are supposed to be exactly equivalent so this is a
major issue:
https://bitbucket.org/zzzeek/sqlalchemy/issues/3505/join-targeting-broken-for-joined-inh
On 8/3/15 11:13 AM, Douglas Russell wrote:
Hi again,
Full code:
what about CLOB type? Unicode only handles String type. Do i need to use
convert_unicode there?
On Mon, Aug 3, 2015 at 6:56 PM, Mike Bayer mike...@zzzcomputing.com wrote:
On 8/1/15 12:12 PM, Abhishek Sharma wrote:
Thanks for help. But still i have confusion over encoding and decoding
Quoting c.bu...@posteo.jp:
I know that in most all RDBMS are no implementations of lists or arrays.
On the contrary - and emphatically - just about every modern RDMBS
supports collection types including lists, sets, multi-sets, and
key-value data. This support has been in most databases
On 8/3/15 1:04 PM, Abhishek Sharma wrote:
what about CLOB type? Unicode only handles String type. Do i need to
use convert_unicode there?
if your CLOB expects non-ascii characters then yes.
though on Oracle I thought you really need to be using NCLOB for a col
that stores unicode.
On
On 8/3/15 1:01 PM, Mike Bayer wrote:
all of those syntaxes are supposed to be exactly equivalent so this is
a major issue:
https://bitbucket.org/zzzeek/sqlalchemy/issues/3505/join-targeting-broken-for-joined-inh
OK, this is not as much of a bug as I thought, though I might be able to
do
On 8/1/15 6:59 PM, Ian McCullough wrote:
I've been getting up to speed with SQLAlchemy and alembic and having a
great time of it. This is some great stuff!
One thing that's been confounding me is this: My Alembic schema
revisions are 'authoritative' for my metadata (i.e. I've started from
On 8/3/15 3:13 AM, c.bu...@posteo.jp wrote:
On 2015-08-02 19:15 c.bu...@posteo.jp wrote:
But what is about SQLAlchemy? I see nowhere a implementation of a
List() type that encapsulate that VARCHAR-depending converting work?
When implementing this myself. I am not sure if I have to use
On 8/1/15 12:12 PM, Abhishek Sharma wrote:
Thanks for help. But still i have confusion over encoding and decoding
procedure which will take place before retrieving and storing the
results in DB.
In case if i am not using convert_unicode option and data type is
String so python process will
Hi all,
after upgrading alembic to 0.7.7 and SQLAlchemy to 1.0.8, when I try to
downgrade one step from head, I get the below KeyError. The allegedly
missing key is the revision ID of head. It is correctly stored in the
alembic table, and the file and its predecessor are also present.
Other
22 matches
Mail list logo
