Re: branch merge schema conflict

['br...@derocher.org' via sqlalchemy-alembic]

Thanks for your quick responses.  We have never downgraded our prod 
database, but I feel it's still nice to have that option.

I was just thinking While I'm thinking there needs to be one migration 
that merges 2 versions, and in my mind it has to work on both 
repositories That's not true.  When merging migrations from one repo 1 
into repo 2... the repo 2 migrations will already be out there on prod.  So 
the order is determined.  Likewise for merging migrations from repo 2 into 
repo 1 if that's needed.

I look forward to 1.6.  I was just watching Selena Deckelmann's video on 
Alembic when it didn't have merging.  The progress here is great.  Thanks.

On Tuesday, March 9, 2021 at 10:36:02 PM UTC-5 mik...@zzzcomputing.com 
wrote:

> just so you know, surgical-precision downgrades will be more reliable once 
> we get the 1.6 series of Alembic out, where we have a total rewrite of how 
> the internal traversal works in order to make upgrade/downgrades across 
> complex trees more reliable.  downgrades are not *too* common in 
> production systems.
>
> On Tue, Mar 9, 2021, at 10:15 PM, 'br...@derocher.org' via 
> sqlalchemy-alembic wrote:
>
> c787 did not fail, nor did 60e8 on upgrade.  According to alembic history, 
> alembic ran 1efb before c787.  So the result is I have a view in my 
> database that will never get used because the query is now embedded in 
> code.  The solution is clear.  60e8 should drop a view if there is one.
>
> For downgrade we get lucky.
>
> I feel the situation could be more diabolic for downgrade.  Unlike code 
> version control, it seems the precondition does not need to exist, at least 
> for views when you change only the body, not the "view signature".  If for 
> example the c787 upgrade as "create or replace view v1 as select 2, 2" then 
> it gets messy.  I don't even know what downgrade would look like.  I assume 
> alembic would undo the last upgrade applied based on history.
>
> For a single repository, only one branch gets into master first.  So that 
> defines the order.  When there's a fork, it gets more complicated.
>
> On Tuesday, March 9, 2021 at 6:12:06 PM UTC-5 mik...@zzzcomputing.com 
> wrote:
>
>
>
>
> On Tue, Mar 9, 2021, at 5:06 PM, 'br...@derocher.org' via 
> sqlalchemy-alembic wrote:
>
> I'm wondering how to solve an issue.
>
> One developer created migration 1efb
>
> upgrade:
>   drop view v1 -- moved to query in the code
>
> downgrade:
>create view v1 as select 1
>
> Another developer created a migration c787
>
> upgrade:
>create or replace view v1 as select 2
>
> downgrade
>create or replace view v1 as select 1
>
> Now I'm merging them with alembic merge heads.  
>
> I get revision = 60e8, down_revision = (c787, 1efb).
>
> My question is which migration runs first.  If 1efb goes first, c787 will 
> fail.  If 1efb goes first upgrade is smooth.
>
> My concern is some databases are at 1efb and some are at c787.  For the 
> database at 1efb, how to I prevent a failure?  Can I put some logic in 
> upgrade() (and downgrade()) to prevent this?
>
>
> seems tricky but does c787 actually fail?  it says "create or replace", so 
> if "v1" was already dropped it would just create a new view. in the 
> other direction, the view is still named "v1" so 1efb will just drop "v1".
>
> if this is not exactly accurate and the name is different or something you 
> can always modify 1efb to read "drop view if exists" and "create or replace 
> view ".if there's no "drop view if exists" on your target DB then I'd 
> stick a quick reflection query in the migration to check if it exists, 
> inspect(engine).get_view_definition() should have that.
>
>
>
>
> Thanks,
> Brian
>
> PS: It's actually a bit more complicated than this because I'm merging git 
> forks.
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy-alem...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy-alembic/e1fe03f2-bc06-4c76-a75b-e8d0efcf4473n%40googlegroups.com
>  
> 
> .
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy-alem...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy-alembic/3873492a-b421-4fe1-b736-9a0d462961a1n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" 

Re: branch merge schema conflict

[Mike Bayer]

just so you know, surgical-precision downgrades will be more reliable once we 
get the 1.6 series of Alembic out, where we have a total rewrite of how the 
internal traversal works in order to make upgrade/downgrades across complex 
trees more reliable.  downgrades are not *too* common in production systems.

On Tue, Mar 9, 2021, at 10:15 PM, 'br...@derocher.org' via sqlalchemy-alembic 
wrote:
> c787 did not fail, nor did 60e8 on upgrade.  According to alembic history, 
> alembic ran 1efb before c787.  So the result is I have a view in my database 
> that will never get used because the query is now embedded in code.  The 
> solution is clear.  60e8 should drop a view if there is one.
> 
> For downgrade we get lucky.
> 
> I feel the situation could be more diabolic for downgrade.  Unlike code 
> version control, it seems the precondition does not need to exist, at least 
> for views when you change only the body, not the "view signature".  If for 
> example the c787 upgrade as "create or replace view v1 as select 2, 2" then 
> it gets messy.  I don't even know what downgrade would look like.  I assume 
> alembic would undo the last upgrade applied based on history.
> 
> For a single repository, only one branch gets into master first.  So that 
> defines the order.  When there's a fork, it gets more complicated.
> 
> On Tuesday, March 9, 2021 at 6:12:06 PM UTC-5 mik...@zzzcomputing.com wrote:
>> 
>> 
>> 
>> On Tue, Mar 9, 2021, at 5:06 PM, 'br...@derocher.org' via sqlalchemy-alembic 
>> wrote:
>>> I'm wondering how to solve an issue.
>>> 
>>> One developer created migration 1efb
>>> 
>>> upgrade:
>>>   drop view v1 -- moved to query in the code
>>> 
>>> downgrade:
>>>create view v1 as select 1
>>> 
>>> Another developer created a migration c787
>>> 
>>> upgrade:
>>>create or replace view v1 as select 2
>>> 
>>> downgrade
>>>create or replace view v1 as select 1
>>> 
>>> Now I'm merging them with alembic merge heads.  
>>> 
>>> I get revision = 60e8, down_revision = (c787, 1efb).
>>> 
>>> My question is which migration runs first.  If 1efb goes first, c787 will 
>>> fail.  If 1efb goes first upgrade is smooth.
>>> 
>>> My concern is some databases are at 1efb and some are at c787.  For the 
>>> database at 1efb, how to I prevent a failure?  Can I put some logic in 
>>> upgrade() (and downgrade()) to prevent this?
>> 
>> seems tricky but does c787 actually fail?  it says "create or replace", so 
>> if "v1" was already dropped it would just create a new view. in the 
>> other direction, the view is still named "v1" so 1efb will just drop "v1".
>> 
>> if this is not exactly accurate and the name is different or something you 
>> can always modify 1efb to read "drop view if exists" and "create or replace 
>> view ".if there's no "drop view if exists" on your target DB then I'd 
>> stick a quick reflection query in the migration to check if it exists, 
>> inspect(engine).get_view_definition() should have that.
>> 
>> 
>>> 
>>> 
>>> Thanks,
>>> Brian
>>> 
>>> PS: It's actually a bit more complicated than this because I'm merging git 
>>> forks.
>>> 

>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "sqlalchemy-alembic" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to sqlalchemy-alem...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sqlalchemy-alembic/e1fe03f2-bc06-4c76-a75b-e8d0efcf4473n%40googlegroups.com
>>>  
>>> .
>> 
> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy-alembic+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy-alembic/3873492a-b421-4fe1-b736-9a0d462961a1n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy-alembic/de6f0fa8-596b-4c12-9bd5-ed0d687904a8%40www.fastmail.com.

Re: branch merge schema conflict

['br...@derocher.org' via sqlalchemy-alembic]

c787 did not fail, nor did 60e8 on upgrade.  According to alembic history, 
alembic ran 1efb before c787.  So the result is I have a view in my 
database that will never get used because the query is now embedded in 
code.  The solution is clear.  60e8 should drop a view if there is one.

For downgrade we get lucky.

I feel the situation could be more diabolic for downgrade.  Unlike code 
version control, it seems the precondition does not need to exist, at least 
for views when you change only the body, not the "view signature".  If for 
example the c787 upgrade as "create or replace view v1 as select 2, 2" then 
it gets messy.  I don't even know what downgrade would look like.  I assume 
alembic would undo the last upgrade applied based on history.

For a single repository, only one branch gets into master first.  So that 
defines the order.  When there's a fork, it gets more complicated.

On Tuesday, March 9, 2021 at 6:12:06 PM UTC-5 mik...@zzzcomputing.com wrote:

>
>
>
> On Tue, Mar 9, 2021, at 5:06 PM, 'br...@derocher.org' via 
> sqlalchemy-alembic wrote:
>
> I'm wondering how to solve an issue.
>
> One developer created migration 1efb
>
> upgrade:
>   drop view v1 -- moved to query in the code
>
> downgrade:
>create view v1 as select 1
>
> Another developer created a migration c787
>
> upgrade:
>create or replace view v1 as select 2
>
> downgrade
>create or replace view v1 as select 1
>
> Now I'm merging them with alembic merge heads.  
>
> I get revision = 60e8, down_revision = (c787, 1efb).
>
> My question is which migration runs first.  If 1efb goes first, c787 will 
> fail.  If 1efb goes first upgrade is smooth.
>
> My concern is some databases are at 1efb and some are at c787.  For the 
> database at 1efb, how to I prevent a failure?  Can I put some logic in 
> upgrade() (and downgrade()) to prevent this?
>
>
> seems tricky but does c787 actually fail?  it says "create or replace", so 
> if "v1" was already dropped it would just create a new view. in the 
> other direction, the view is still named "v1" so 1efb will just drop "v1".
>
> if this is not exactly accurate and the name is different or something you 
> can always modify 1efb to read "drop view if exists" and "create or replace 
> view ".if there's no "drop view if exists" on your target DB then I'd 
> stick a quick reflection query in the migration to check if it exists, 
> inspect(engine).get_view_definition() should have that.
>
>
>
> Thanks,
> Brian
>
> PS: It's actually a bit more complicated than this because I'm merging git 
> forks.
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy-alem...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy-alembic/e1fe03f2-bc06-4c76-a75b-e8d0efcf4473n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy-alembic/3873492a-b421-4fe1-b736-9a0d462961a1n%40googlegroups.com.

Re: branch merge schema conflict

[Mike Bayer]

On Tue, Mar 9, 2021, at 5:06 PM, 'br...@derocher.org' via sqlalchemy-alembic 
wrote:
> I'm wondering how to solve an issue.
> 
> One developer created migration 1efb
> 
> upgrade:
>   drop view v1 -- moved to query in the code
> 
> downgrade:
>create view v1 as select 1
> 
> Another developer created a migration c787
> 
> upgrade:
>create or replace view v1 as select 2
> 
> downgrade
>create or replace view v1 as select 1
> 
> Now I'm merging them with alembic merge heads.  
> 
> I get revision = 60e8, down_revision = (c787, 1efb).
> 
> My question is which migration runs first.  If 1efb goes first, c787 will 
> fail.  If 1efb goes first upgrade is smooth.
> 
> My concern is some databases are at 1efb and some are at c787.  For the 
> database at 1efb, how to I prevent a failure?  Can I put some logic in 
> upgrade() (and downgrade()) to prevent this?

seems tricky but does c787 actually fail?  it says "create or replace", so if 
"v1" was already dropped it would just create a new view. in the other 
direction, the view is still named "v1" so 1efb will just drop "v1".

if this is not exactly accurate and the name is different or something you can 
always modify 1efb to read "drop view if exists" and "create or replace view ". 
   if there's no "drop view if exists" on your target DB then I'd stick a quick 
reflection query in the migration to check if it exists, 
inspect(engine).get_view_definition() should have that.


> 
> Thanks,
> Brian
> 
> PS: It's actually a bit more complicated than this because I'm merging git 
> forks.
> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy-alembic+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy-alembic/e1fe03f2-bc06-4c76-a75b-e8d0efcf4473n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy-alembic/2aee3837-7e4d-4e6b-a537-a26f64dbe1a1%40www.fastmail.com.

branch merge schema conflict

['br...@derocher.org' via sqlalchemy-alembic]

I'm wondering how to solve an issue.

One developer created migration 1efb

upgrade:
  drop view v1 -- moved to query in the code

downgrade:
   create view v1 as select 1

Another developer created a migration c787

upgrade:
   create or replace view v1 as select 2

downgrade
   create or replace view v1 as select 1

Now I'm merging them with alembic merge heads.  

I get revision = 60e8, down_revision = (c787, 1efb).

My question is which migration runs first.  If 1efb goes first, c787 will 
fail.  If 1efb goes first upgrade is smooth.

My concern is some databases are at 1efb and some are at c787.  For the 
database at 1efb, how to I prevent a failure?  Can I put some logic in 
upgrade() (and downgrade()) to prevent this?

Thanks,
Brian

PS: It's actually a bit more complicated than this because I'm merging git 
forks.

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy-alembic/e1fe03f2-bc06-4c76-a75b-e8d0efcf4473n%40googlegroups.com.

Re: [sqlalchemy] Supporting Function Indexes on a Minimum Sqlite Version

['Jonathan Vanasco' via sqlalchemy]

Thank you so much, Mike!

I roughly had that same @compiles in my tests, but I didn't trust myself... 
and the .dbapi looked like what I wanted, but I really wasn't sure!
On Monday, March 8, 2021 at 4:36:03 PM UTC-5 Mike Bayer wrote:

>
>
> On Mon, Mar 8, 2021, at 12:06 PM, 'Jonathan Vanasco' via sqlalchemy wrote:
>
> I have a project that, in a few rare situations, may run on a version of 
> sqlite that does not support function indexes, and "need" to run a unique 
> index on `lower(name)`.  For simplicity, I'll just use a normal index on 
> correct systems,
>
> I'm trying to figure out the best way to implement this.
>
> 1. in terms of sqlite3, what is the best way to access the version 
> Sqlalchemy is using?  the import is in a classmethod, and could either be 
> pysqlite2 or sqlite3?  i seriously doubt anyone would deploy with 
> pysqlite2, but I feel like I should do things the right way.
>
>
> you'd get this from the dbapi:
>
> >>> from sqlalchemy import create_engine 
> >>> e = create_engine("sqlite://")
> >>> e.dialect.dbapi.sqlite_version
> '3.34.1'
>
>
>
>
>
> 2. What is the best way to implement this contextual switch?  I thought 
> about a `expression.FunctionElement` with custom `@compiles`.
>
>
> yeah that is probably the best approach
>
> from sqlalchemy.sql import expression
> from sqlalchemy.ext.compiler import compiles
>
> class maybe_lower(expression.FunctionElement):
> type = String()
>
> @compiles(maybe_lower, 'sqlite')
> def sl_maybe_lower(element, compiler, **kw):
> args = list(element.clauses)
> if compiler.dialect.dbapi_version < ...:
> return "LOWER(%s)" % (compiler.process(args[0], **kw))
> else:
> return compiler.process(args[0], **kw)
>
> @compiles(maybe_lower)
> def default_maybe_lower(element, compiler, **kw):
> args = list(element.clauses)
> return compiler.process(args[0], **kw)
>
>
>
>
>
> -- 
> 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 Example. See http://stackoverflow.com/help/mcve for a full 
> description.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/99598f81-3851-4f2c-988c-1560d2f5e906n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
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 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/106d60b5-8610-42a4-9738-bd27788b253bn%40googlegroups.com.

Re: [sqlalchemy] can you insert data for a model with a many to many relationship using alembic?

[Mike Bayer]

bulk_insert_mappings doesn't handle relationships in any case, if you wanted 
relationships to be persisted without doing the INSERT yourself you would need 
to use regular ORM Session unit of work patterns.

In Alembic, you would need to use ORM mappings inside of your alembic scripts, 
which is perfectly acceptable, the only issue with that is that if you import 
these models from your application, they might not match the state of the 
database for when the migration is running.so it might be better to create 
an ad-hoc mapping in your migration file.   Depending on how you are getting 
those Table objects, you can assign them to a new declarative model using 
__table__ (See 
https://docs.sqlalchemy.org/en/14/orm/declarative_tables.html#orm-imperative-table-configuration
 )   and you can make a new Session for the local transaction using 
Session(op.get_bind()).

if you wanted bulk_insert_mappings to apply directly to your manytomany table 
then you can map a class to that table and use the method, but I dont see much 
advantage to this vs. using plain table.insert(), in both cases it's a command 
with a list of dictionaries.


if you are looking to use session.flush(), that implies you should just use 
traditional unit of work patterns and you wouldn't be using 
bulk_insert_mappings, which is a special case method that IMO is not actually 
very useful compared to other APIs that already exist.


On Tue, Mar 9, 2021, at 9:58 AM, maqui...@gmail.com wrote:
> I'm trying to create an alembic bulk insert statement to add a row into a 
> model that has a relationship (many-to-many) with another table but don't 
> know if this is possible or if so what syntax to use.
> 
> In my current alembic file I do this in two or more steps:
> 1.) I add the rows to the table represented by the model
> 2.) I add the rows to the mixer table for the model and its related 
> model/table
> 
> like so:
> g.session.bulk_insert_mappings(
> CvConfiguration,
> [
> {
> "controlled_vocabulary_type_id": controlled_vocabulary_type(
> "cv_vessel_type"
> ),
> "default_cv_id": cv_vessel_type("well_plate"),
> },
> ],
> return_defaults=True,
> )
> 
> g.session.flush()
> 
> mix_cv_organization_cv_configuration_stmt = 
> mix_cv_organization_cv_configuration.insert().values(
> [
> {
> "cv_organization_id": 
> cv_organization("biologics_generation_group"),
> "cv_configuration_id": cv_configuration("cv_vessel_type", 
> "well_plate"),
> },
> ],
> )
> g.session.execute(mix_cv_organization_cv_configuration_stmt)
> 
> I'd really like to combine the relationship into the bulk_insert_mapping if 
> possible, so if the relationship on the SqlAlchemy model is called 
> "used_by_cv_organizations" my insert looks something like this, with the 
> foreign key objects in a list or something.
> 
> g.session.bulk_insert_mappings(
> CvConfiguration,
> [
> {
> "controlled_vocabulary_type_id": controlled_vocabulary_type(
> "cv_vessel_type"
> ),
> "default_cv_id": cv_vessel_type("well_plate"),
> "used_by_cv_organizations": [
> cv_organization("biologics_generation_group")
> ],
> },
> ],
> return_defaults=True,
> )
> 
> g.session.flush()
> 
> Is this possible? Does anyone know how to do it?
> 
> 
> 

> -- 
> 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 Example. See http://stackoverflow.com/help/mcve for a full 
> description.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/f7ddef2f-9152-4b5a-a60e-bf51794f531bn%40googlegroups.com
>  
> .

-- 
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 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/766fc0ee-2555-47f4-9720-5dbc06e4%40www.fastmail.com.

[sqlalchemy] can you insert data for a model with a many to many relationship using alembic?

[maqui...@gmail.com]

I'm trying to create an alembic bulk insert statement to add a row into a 
model that has a relationship (many-to-many) with another table but don't 
know if this is possible or if so what syntax to use.

In my current alembic file I do this in two or more steps:
1.) I add the rows to the table represented by the model
2.) I add the rows to the mixer table for the model and its related 
model/table

like so:
g.session.bulk_insert_mappings(
CvConfiguration,
[
{
"controlled_vocabulary_type_id": controlled_vocabulary_type(
"cv_vessel_type"
),
"default_cv_id": cv_vessel_type("well_plate"),
},
],
return_defaults=True,
)

g.session.flush()

mix_cv_organization_cv_configuration_stmt = 
mix_cv_organization_cv_configuration.insert().values(
[
{
"cv_organization_id": 
cv_organization("biologics_generation_group"),
"cv_configuration_id": cv_configuration("cv_vessel_type", 
"well_plate"),
},
],
)
g.session.execute(mix_cv_organization_cv_configuration_stmt)

I'd really like to combine the relationship into the bulk_insert_mapping if 
possible, so if the relationship on the SqlAlchemy model is called 
"used_by_cv_organizations" my insert looks something like this, with the 
foreign key objects in a list or something.

g.session.bulk_insert_mappings(
CvConfiguration,
[
{
"controlled_vocabulary_type_id": controlled_vocabulary_type(
"cv_vessel_type"
),
"default_cv_id": cv_vessel_type("well_plate"),
"used_by_cv_organizations": [
cv_organization("biologics_generation_group")
],
},
],
return_defaults=True,
)

g.session.flush()

Is this possible? Does anyone know how to do it?


-- 
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 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/f7ddef2f-9152-4b5a-a60e-bf51794f531bn%40googlegroups.com.

Re: [sqlalchemy] Exception on '.refresh' for certain objects - state.load_path Tuple is empty

[Mike Bayer]

still kind of weird, I am not seeing any issue like this that was fixed, 
wouldn't mind seeing a reproducer case but no worries.


On Mon, Mar 8, 2021, at 6:44 PM, Gmoney wrote:
> Looks like that did the trick!  Should have tried that first, but got lazy 
> when conda was resisting my update attempts earlier.
> Thank you
> On Monday, March 8, 2021 at 4:38:13 PM UTC-5 Mike Bayer wrote:
>> __
>> it looks like a bug unless you are manipulating the InstanceState.   I would 
>> upgrade to SQLAlchemy 1.3.23 first to make sure it hasn't been fixed.
>> 
>> 
>> 
>> On Mon, Mar 8, 2021, at 1:09 PM, Gmoney wrote:
>>> On python 3.7 SQLAlchemy 1.3.13
>>> I'm running into an issue when doing a session.refresh(orm_object) where 
>>> for certain objects it throws an exception because in line 709 of 
>>> orm/loading.py, the 'state.load_path' is an empty tuple.  Attached the 
>>> relevant snippet of the stack dump below.
>>> 
>>> This was simple test with no actual changes:  
>>> task = Task.query.filter(blah).one()
>>> session.refresh(task)
>>> Again it works for some, not for others.
>>> 
>>> Is there was something obvious that might cause this - perhaps I'm 
>>> misunderstanding how refresh works?  We have numerous relationships on the 
>>> model that often refer to the same table (multiple 'user_id' fk 
>>> references).  This hasn't causes us any other issues, but it's worth noting.
>>> 
>>> I will try to pare down the model to isolate what the cause is, and follow 
>>> up with a test case if I can.  But wanted to see if it was anything obvious 
>>> before I dig too deep.
>>> 
>>>   File "/-/lib/python3.7/site-packages/sqlalchemy/orm/loading.py", line 
>>> 709, in _populate_full

>>> elif load_path != state.load_path:

>>>   File "-/lib/python3.7/site-packages/sqlalchemy/orm/path_registry.py", 
>>> line 63, in __eq__

>>> return other is not None and self.path == other.path

>>> AttributeError: 'tuple' object has no attribute 'path'

>>>  

>>> 
>>> 
>>> 
>>> 

>>> -- 
>>> 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 Example. See http://stackoverflow.com/help/mcve for a full 
>>> description.
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "sqlalchemy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to sqlalchemy+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sqlalchemy/007a8cae-33bc-4b5f-bdf3-e8abe1dee358n%40googlegroups.com
>>>  
>>> .
>> 
> 

> -- 
> 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 Example. See http://stackoverflow.com/help/mcve for a full 
> description.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/9a8cd7e3-1c30-48be-81af-7a0ff4d8a5acn%40googlegroups.com
>  
> .

-- 
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 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/b11777b1-786e-483c-9ae0-7253bbb477dc%40www.fastmail.com.