Polymorphic relations broke SQL Transactions about loopback-next

[mgabeler-lee-6rs]

I don't use them, but it looks like this bug will affect pretty much every SQL connector, not just PG, since they all have copies of the same "is this my transaction" check:

• https://github.com/loopbackio/loopback-connector-mysql/blob/9045ad868ce07e5b7468429566c358ea5fdbf9f6/lib/mysql.js#L246
• https://github.com/loopbackio/loopback-connector-oracle/blob/ba7f88886dd49b091c54e25d5d08421ac934c680/lib/oracle.js#L208
• https://github.com/loopbackio/loopback-connector-sqlite3/blob/f72c27bfaadc2b58e6dec8427bd572bd70c0da14/lib/sqlite3.js#L158
• https://github.com/loopbackio/loopback-connector-mssql/blob/cfb97efa83e0684446a1ed617c3c6bca95279d92/lib/mssql.js#L121

[mgabeler-lee-6rs]

@OnTheThirdDay as the author of the PR that caused this, any thoughts?

It looks like this could be fixed by just using a shallow clone / spread of the options object instead of a deep clone?

[OnTheThirdDay]

Oh I see.. would the following work? I think maybe just don't clone it would be fine. Sorry that I can't quite remember why I deep-cloned it instead of using the options directly..

Object.assign(options ?? {}, {polymorphicType: key}),

@mgabeler-lee-6rs

[mgabeler-lee-6rs]

@OnTheThirdDay Yep, that's roughly what I submitted as #10195, but I used spread syntax in my PR. Is there a particular benefit of using Object.assign here instead of a spread?

[OnTheThirdDay]

@mgabeler-lee-6rs I think not much difference, just a styling thing across the repo.