On Mon, Jun 17, 2019, at 12:02 PM, João Miguel Neves wrote:
> Hi,
>
> Ok, versioning adds a different requirement level, as it fails if the version
> being updated has changed. I was looking for a situation where updating 2
> keys inside a JSONB field wouldn't lose one of them. Using
On Mon, Jun 17, 2019, at 12:02 PM, João Miguel Neves wrote:
> Hi,
>
> Ok, versioning adds a different requirement level, as it fails if the version
> being updated has changed. I was looking for a situation where updating 2
> keys inside a JSONB field wouldn't lose one of them. Using
Hi,
Ok, versioning adds a different requirement level, as it fails if the
version being updated has changed. I was looking for a situation where
updating 2 keys inside a JSONB field wouldn't lose one of them. Using
versioning it raises an exception when writing one of them (which is better
than
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
>
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
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
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
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
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,
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
>
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
11 matches
Mail list logo
