Re: [sqlalchemy] inserted_primary_key in version 1.4.

2021-05-13 Thread Mike Bayer
So the use case you are doing there was never something supported, and in particular the value you are getting on 1.3 is not really universally reliable, as it is relying upon cursor.lastrowid that is not defined for multiple-row inserts, even though for InnoDB specifically the behavior is

[sqlalchemy] inserted_primary_key in version 1.4.

2021-05-13 Thread Thorsten von Stein
I use SQLAlchemy with MySQL. In one application, I need to obtain the server-generated primary key values of newly inserted rows by obtaining the value of the first inserted row with the property inserted_primary_key. However, after upgrading to version 1.4.15, this property return only

Re: [sqlalchemy] Rationale for why 1.4 Core `select` argument as list is deprecated?

2021-05-13 Thread mkmo...@gmail.com
Hi Mike, would you mind elaborating on why a library needs to support typing to remain relevant? For example, does it have some potential impact on downstream users of a library who want to take advantage of typing? I have a (very small) library, and is completely untyped. I don't really like

Re: [sqlalchemy] Rationale for why 1.4 Core `select` argument as list is deprecated?

2021-05-13 Thread Mike Bayer
Python is going towards using typing, period. Any widely used library has to support this fully to remain relevant, so even if we didn't like typing, we still have to support it :) . It has no impact on you as a user of the library, you can ignore typing completely and there's no issue

Re: [sqlalchemy] Rationale for why 1.4 Core `select` argument as list is deprecated?

2021-05-13 Thread mkmo...@gmail.com
Hi Mike. Thanks, it makes sense. On another topic, the docs say: However, version 2.0 hopes to start embracing *PEP 484* and other new features to a great degree Would you please explain why SQLAlchemy wants to move to embracing type hints to

Re: [sqlalchemy] Rationale for why 1.4 Core `select` argument as list is deprecated?

2021-05-13 Thread Mike Bayer
SQLAlchemy has a general philosophy of fn(*args) vs fn(list): 1. if the sequence of items represents **database data**, we use a **list** or other inline sequence. E.g. in_(): column.in_([1, 2, 3]) 2. if the sequence of items represents **SQL structure**, we use a variable length

[sqlalchemy] Rationale for why 1.4 Core `select` argument as list is deprecated?

2021-05-13 Thread mkmo...@gmail.com
Hello, I am on Sqlalchemy 1.2 and looking to upgrade to 1.4. I have a lot of Core code that looks like this: # returns an array of columns select_fields = make_select_fields(...) sel = select(select_fields) Passing an array to select is now deprecated, so I'm planning on changing