Thanks for the detailed explanation!
On 28 February 2017 at 16:22, mike bayer wrote:
> sorry, lost track on this one.
>
> On 02/15/2017 10:07 PM, Zsolt Ero wrote:
>>
>> I'm starting to understand it! Just a few very quick questions:
>>
>> 1. Is it a good strategy to always use onupdate='CASCADE',
sorry, lost track on this one.
On 02/15/2017 10:07 PM, Zsolt Ero wrote:
I'm starting to understand it! Just a few very quick questions:
1. Is it a good strategy to always use onupdate='CASCADE',
ondelete='CASCADE' for all foreign keys if the db supports it (in my
case Postgres 9.5 + psycopg2)?
Can anyone help with these questions? Nothing urgent, I'm just
interested in understanding more about SQLAlchemy.
On 16 February 2017 at 04:07, Zsolt Ero wrote:
> I'm starting to understand it! Just a few very quick questions:
>
> 1. Is it a good strategy to always use onupdate='CASCADE',
> ondel
I'm starting to understand it! Just a few very quick questions:
1. Is it a good strategy to always use onupdate='CASCADE',
ondelete='CASCADE' for all foreign keys if the db supports it (in my
case Postgres 9.5 + psycopg2)?
2. If I'd like to use it on an already populated db, can I "alter
table" t
On 02/15/2017 09:45 AM, Zsolt Ero wrote:
4. An interesting thing is that SQLAlchemy does 3 select calls in the
delete case, even if 1 would be enough. Can be seen in the logs.
the ORM only deletes rows one at a time based on primary key match. So
if you have a relationship() that is config
Thank you for the explanation! It is indeed deeper than I first
thought, but I understand it now.
Finally, consider question 4. (multiple select on delete) to be a bug
report, even if harmless.
On 15 February 2017 at 17:07, mike bayer wrote:
> a "delete" cascade can be done on the client side
a "delete" cascade can be done on the client side because it involves a
simple ordering of steps:
1. DELETE the rows that depend on the target row
2. DELETE the target row.
an "update" cascade, OTOH, can't work this way. Because the dependent
row remains existing and needs to have a primary
Thanks a lot! I would be still interested in your answer for 3. and 4.
Especially, what is the difference between update and delete from's
behaviour here? Why
does SQLAlchemy know how to "cascade" a delete just on the client
side, while for update it needs server side CASCADE support?
On 15 Fe
onupdate=CASCADE is an option of ForeignKey, not Column:
Table(
'collections_images', Base.metadata,
Column('collection_id',
ForeignKey('collections.id', onupdate='CASCADE'),
primary_key=True, ),
Column('image_id', ForeignKey('images.id'), primary_key=True))
On 02/15/2
Thanks Mike for looking into this.
I've created a minimal program which reproduces my error. As a
context, this is a init script for a Pyramid app, but is run from
command line, not in a request loop. The tables are dropped and
recreated at start. Inklesspen helped me figure out the transaction
ma
On 02/14/2017 08:15 PM, Zsolt Ero wrote:
I would like to change a primary key's value, to be deterministic, based
on a multi-to-multi relation. Thus I'm populating the tables with a
temporary ids (just random strings), then calculating the right, unique
id, and changing it afterwards.
the exa
I would like to change a primary key's value, to be deterministic, based on
a multi-to-multi relation. Thus I'm populating the tables with a temporary
ids (just random strings), then calculating the right, unique id, and
changing it afterwards.
I have the following models:
class Image(Base):
12 matches
Mail list logo
