-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API: SQL legacy mode to_sql 'index' kwarg behaviour #6881
Comments
In the long term, I'd like to keep full-fledged support for connections generated by So, I'd like to build MultiIndex support for legacy connections. |
Hmm, that's maybe indeed a good division. This would mean to deprecate the mysql flavor, and only keeping the slqite flavor. I think it wouldn't be that difficult to add multi-index support to the legacy mode (actually a lot of the code can be reused I think. I will look at it). |
and at once also index_label kwarg support
@danielballan Pushed a PR for multi-index (and index_label specifying) support in legacy mode. This just leaves the issue that this is actually an api change, so could possibly break code. |
and at once also index_label kwarg support
A leftover from #6735. In this PR, multi-index support was added to the new
to_sql
andread_table
functions based on sqlalchemy. However, I did not change anything in the legacyto_sql
functions.This has the following consequences for the
index
handling in legacy mode (https://github.com/pydata/pandas/blob/18bd0d64bf1fcdc7e86e743332dab29e9a155909/pandas/io/sql.py#L808):con
type (dbapi connection or sqlalchemy connection), writing a multi-index dataframe will work or generate an error.write_frame
(asto_sql
did not yet exist)We could also opt to remove this entirely from the legacy mode (leave it as it was). However this is also somewhat complicated, as it is not easy to detect when the
index
keyword is specified by the user in legacy mode (in order to warn that this is ignored), as it is set to True by default. But it seems to me that we should either support it fully (with multi-index as for sqlalchemy based), or not.But maybe more in general: how do we see the 'legacy'? Just keep it for backwards compatibility? Or is it useful to have something that is not dependent on sqlalchemy? (so also enhance it? or only bug fixes?)
@hayd @mangecoeur @danielballan
The text was updated successfully, but these errors were encountered: