refactor(api): ddl accessor

[ncclementi]

• Inspired on feat(ddl): distinguish views from tables while listing them #8864
• Closes : feat: Ability to Distinguish between Table and Views #8382

Very rough start, so far I created the DDL accessor and I'm trying to get to run the some methods as they are (no changes yet to functionality) from the accessor like con.ddl.list_, this works. But I'm having problems triggering the deprecation when doing con.list_.

I thought if I deprecate the abstract methods that would do it, but it doesn't because it looks immediately for the backend specific implementation. Not sure what's the best solution here design wise.

** How do we deprecate in this case? **
If I move the deprecation to the Backend implementation of let's say list_tables as an example, it will trigger both when doing con.list_tables() and con.ddl.list_tables()

One option would be taking the methods out of the backend class, to a let's say DDL and access them via the accessor, and when the ones on the Backend class get accessed con.list_ they'll warn and point to the con.ddl.list_. If we do this, I wonder if having a DDLBase with all abstract methods might make sense here, something similar to what we do with the BaseBackend one.

EDIT:
After discussing with Gil here are the steps to proceed:

• remove ddl abstract methods in BaseBackend (like list_tables)
• deprecate list_* in Backend specific
• create _list_* in Backend specific
• create list_* in the ddl accessor, point it to the self._backend._list_* method

TODO:

• Get all the list_* related work, working for duckdb
• Move to other backends
• Leave other ddl operations to followup PR for simplicity.

cc: @gforsyth for when you are back

[github-actions]

ACTION NEEDED

Ibis follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message.

Please update your PR title and description to match the specification.

[ncclementi]

@gforsyth I did a first path at

• Implementing the list_* for duckdb
• Safeguarding the DDLAccessor with a higher level of NotImplementedError.
• Modifying con.tables to use list_* making sure that it uses the one that are implemented for the specific backend.
• Added api tests for all the list_* and one for modified the previous con.list_tables test (now named test_list_all_tables_and_views)

Right now we have a lot of tests that rely on asserts that use con.list_tables I haven't modified any of them yet since in some cases it should be con.tables and others might be con.ddl.list_tables. If we are good with this idea/design, I'll move forward with cleaning up tests and start working on the other backends.

[ncclementi]

I'm trying to get the DuckDB backend green so I can move on to the other backend's implementation but I'm having a few issues that I idk where they are coming from. I think if we can fix those we are on a safe point to move onto the other backends.

[ncclementi]

Discussion for postgres:

So, we are currently on main doing something weird with list_tables() in postgres that doesn't match necessarily any behavior in psotgres sql.

I created a table, a temp table, a view a temp view and a foreign table in psql.

• \dt only lists table and temp table
• \dv only lists view and temp view
• \det only list foreign table
• \dvtE list them all

on Ibis con.list_tables()

• lists the view, table, and foreign table (no temp table or temp view)

On the PR I propose,

• having the same than in duckdb case list_tables, list_temp_tables, list_views, list_temp_views
• add list_foreign_tables
• con.tables: list them all

@gforsyth @cpcloud does this sound reasonable?

[gforsyth]

does this sound reasonable?

yeah, I think that sounds good!