Thank you Mike! You're right -- I had in mind the latter but used the
terminology more suited to the former.
Berislav
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Cool, wasn't aware of that feature! Thanks!
On Fri, Jun 14, 2019 at 5:50 PM Mike Bayer wrote:
>
>
> On Fri, Jun 14, 2019, at 12:46 PM, Mike Bayer wrote:
>
>
>
> On Fri, Jun 14, 2019, at 12:22 PM, João Miguel Neves wrote:
>
> Not performance, actually to avoid a race condition with key/values
> w
On Fri, Jun 14, 2019, at 12:46 PM, Mike Bayer wrote:
>
>
> On Fri, Jun 14, 2019, at 12:22 PM, João Miguel Neves wrote:
>> Not performance, actually to avoid a race condition with key/values written
>> to JSONB fields. Ended up with the following function that we use for when
>> multiple updat
On Fri, Jun 14, 2019, at 12:30 PM, Jonathan Vanasco wrote:
>
>
> On Friday, June 14, 2019 at 9:33:49 AM UTC-4, Mike Bayer wrote:
>> docs for this general idea are at
>> https://docs.sqlalchemy.org/en/13/core/custom_types.html#redefining-and-creating-new-operators
>> but this is likely a good
On Fri, Jun 14, 2019, at 12:22 PM, João Miguel Neves wrote:
> Not performance, actually to avoid a race condition with key/values written
> to JSONB fields. Ended up with the following function that we use for when
> multiple updates at the same time can occur (from the frontend mostly). It's
On Friday, June 14, 2019 at 9:33:49 AM UTC-4, Mike Bayer wrote:
>
> docs for this general idea are at
> https://docs.sqlalchemy.org/en/13/core/custom_types.html#redefining-and-creating-new-operators
>
> but this is likely a good example to add
>
Mike- This is actually a great example to add,
Not performance, actually to avoid a race condition with key/values written
to JSONB fields. Ended up with the following function that we use for when
multiple updates at the same time can occur (from the frontend mostly).
It's based on your recommendations from
https://groups.google.com/forum/#!to
On Fri, Jun 14, 2019, at 11:49 AM, João Miguel Neves wrote:
> Hi Mike,
>
> Thank you very much for the quick response!
>
> Is there any other way to find the right table from the model other than
> somthing like Engineer.name.property.columns[0].table? (I'm trying to do an
> update in a codep
Hi Mike,
Thank you very much for the quick response!
Is there any other way to find the right table from the model other than
somthing like Engineer.name.property.columns[0].table? (I'm trying to do an
update in a codepath that can have several different models passed to it)
TIA,
João
On Fri, J
On Fri, Jun 14, 2019, at 10:30 AM, João Miguel Neves wrote:
> Hi,
>
> I have a situation where an update tries to update the wrong table on when a
> column comes from the parent table and is not on the current table. I'll
> grant I didn't quite understand all the caveats in
> https://docs.sql
Hi,
I have a situation where an update tries to update the wrong table on when
a column comes from the parent table and is not on the current table. I'll
grant I didn't quite understand all the caveats in
https://docs.sqlalchemy.org/en/13/orm/query.html#sqlalchemy.orm.query.Query.update
so le
On Fri, Jun 14, 2019, at 6:22 AM, Berislav Lopac wrote:
> Hi, does anyone know of a simple way to apply a (SQL) function to each and
> every query in an ORM model? For example, this article[0] suggests building a
> lower()-based index for emails in order to normalise them, and then using
> low
Hi, does anyone know of a simple way to apply a (SQL) function to each and
every query in an ORM model? For example, this article[0] suggests building
a lower()-based index for emails in order to normalise them, and then using
lower() every time you search for an email: select * from users where
13 matches
Mail list logo
