Github user gatorsmile commented on the issue:
https://github.com/apache/spark/pull/14086
> `TRUNCATE` is the lower privilege than DROP/CREATE.
This is not true. For example, in DB2 z, `DROP` and `TRUNCATE` require
different privilege.
https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_truncate.html
https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_drop.html
- Drop table will not drop the descendant tables, unless you explicitly
specify `CASCADE`. The behaviors of `TRUNCATE` depends on the vendors.
`TRUNCATE` is not included in the SQL ANSI standards until 2008. That might be
the reason why different vendors behave very differently.
- Rollback may be not an issue here, but it means the deletion log records
are not written into the log. Does it matter? It really depends on how the
applications use the output table of `DataFrameWriter` and the recovery log
they generated. The product I previously worked is to parse and utilize the
transaction recovery log of different RDBMS. Thus, I knew `Truncate` is a big
issue for most replication products.
I just share what I learned here. Developing a general solution for
different JDBC data sources is always very very complicated. When more and more
enterprise customers start using Spark, we will get more and more `strange`
JIRAs.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
