I'm trying to recreate the following SQL in SQLAlchemy:
update ignore abms_biog a join
(select a.id, u.id as user_id from abms_biog a
join 3md.users u on u.firstname = a.firstname
and u.lastname = a.lastname
and 3md.non_conflict_middlename(u.middlename, a.middlename)=1
and u.credentials in
I'm trying to recreate the following SQL in SQLAlchemy:
update ignore abms_biog_%s a
join
(select a.id, u.id as user_id
from abms_biog_%s a
join 3md.users u on u.firstname = a.firstname
and u.lastname = a.lastname
and 3md.non_conflict_middlename(u.middlename, a.middlename)=1
and u.credentials
Thanks for your help, Mike!
Douglas
On Thu, 11 Aug 2016 at 17:14 Mike Bayer wrote:
>
>
> On 08/11/2016 03:35 PM, Douglas Russell wrote:
> > Of course! That makes sense.
> >
> > Does SQLAlchemy just discard the subqueryload chain parts that are on
> > the wrong type?
On 08/11/2016 03:35 PM, Douglas Russell wrote:
Of course! That makes sense.
Does SQLAlchemy just discard the subqueryload chain parts that are on
the wrong type? It didn't seem to generate any SQL for those when they
were wrong.
it validates the path as far as classes / attributes, but I
Of course! That makes sense.
Does SQLAlchemy just discard the subqueryload chain parts that are on the
wrong type? It didn't seem to generate any SQL for those when they were
wrong.
An example of this in the docs would be a great idea I think as I think
it's pretty tough to explain this in
On 08/11/2016 01:24 PM, Demitri Muna wrote:
Hi Mike,
It looks like my Base class was not exactly the same (although it was in
my original code), but this is not the problem.
I didn't think it was, but it's very difficult for me to be helpful when
I only get various out of context lines of
Hi Mike,
It looks like my Base class was not exactly the same (although it was in my
original code), but this is not the problem. I have a custom
"DatabaseConnection" Python class that is a singleton and encapsulates the
database connection. It's constructed like this:
me.engine =
On 08/11/2016 03:30 AM, Wibowo Arindrarto wrote:
Dear all,
I have a little problem with getting object states that have been
flushed but not committed. As far as I understand, SQLAlchemy does not
have an official object state corresponding to this.
The Session is intended to only be working
On 08/11/2016 09:53 AM, Douglas Russell wrote:
of_type was what I was searching for. Thanks.
Unfortunately, it did not yield the desired results when I extended the
hierarchy to 3 levels (C->C2 with a relation between B and C).
I've updated the Gist.
B+B2 is successfully queried, but C+C2
of_type was what I was searching for. Thanks.
Unfortunately, it did not yield the desired results when I extended the
hierarchy to 3 levels (C->C2 with a relation between B and C).
I've updated the Gist.
B+B2 is successfully queried, but C+C2 is not. This will then result in
lazily generated
Hi Simon,
The purpose was to flag those contained objects. These objects are created
by the application's users (both container and contained). The user can
either create the contained objects manually and let the application infer
the container, or they can also create the containers manually.
On Thu, Aug 11, 2016 at 8:30 AM, Wibowo Arindrarto
wrote:
> Dear all,
>
> I have a little problem with getting object states that have been flushed
> but not committed. As far as I understand, SQLAlchemy does not have an
> official object state corresponding to this.
Hi,
first of all, thanks for SQLAlchemy - it's the one project that actually
made me enjoy working with large data collections in applications ;)!
I have an SQLAlchemy model that associates tags (key/value pairs) with
elements, like in attached mwe.py.
Element.tags is a dictionary
Dear all,
I have a little problem with getting object states that have been flushed
but not committed. As far as I understand, SQLAlchemy does not have an
official object state corresponding to this. However, in my application I
need to track such objects. My current approach is to listen to
14 matches
Mail list logo