bug: Strange behavior using .cache method

[augcollet]

What happened?

Hello,

As explained in another thread, I encounter some issues using Ibis quite intensively across different modules; but I usually can't reproduce the issues I encounter in minimal reproducible cases.

While doing various tests, I still managed to observe some strange behavior during the construction of a minimal script using .cache() features.

In the following example below, I build 2 tables that I cache directly. When I display them, the first table is empty but it should not be:

When I deactivate the first .cache, it is the second table that is considered empty:

If I deactivate the 2 .cache, both tables are correct:

Strangely still: if I activate the 2 .cache but I use an .execute on the first table BEFORE creating the second table, both tables are correct:

And finally, if I activate the 2 .cache but I use an .execute on the first table AFTER creating the second, the first table is considered empty:

Here is base code I use :

import ibis
import os
from ibis import _

con=ibis.postgres.connect(
    user=os.getenv('POSTGRES_USER'),
    password=os.getenv('POSTGRES_PASSWORD'),
    host="postgres",
    port=os.getenv('POSTGRES_PORT'),
    database=os.getenv('POSTGRES_DB') 
)

ibis.set_backend(con)

table_1 = ibis.memtable({
    'key': [1,2], 
}).cache()

#table_1.execute()

table_2 = ibis.memtable({
    'key': [3,4],
}).cache()

display('table_1', table_1.execute())
display('table_2', table_2.execute())

Do you have the same behavior on your side? What can explain this?

Thank you in advance,

Regards

What version of ibis are you using?

Name: ibis-framework
Version: 9.5.0
Summary: The portable Python dataframe library
Home-page: https://ibis-project.org/
Author: Ibis Maintainers
Author-email: [email protected]
License: Apache-2.0
Location: /home/user/.local/lib/python3.12/site-packages
Requires: atpublic, parsy, python-dateutil, pytz, sqlglot, toolz, typing-extensions
Required-by:

What backend(s) are you using, if any?

PostgreSQL 16.4 (Debian 16.4-1.pgdg120+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[cpcloud]

Thanks for the issue! This does indeed look very confusing 😆

Taking a look today, and hopefully we can iron out the problem here.

[cpcloud]

@augcollet I cannot reproduce this on main. I think this was fixed in either 10.0.0 or 10.1.0. Closing, but I'll update with my investigation after I finish bisecting.

[cpcloud]

This appears to have been fixed by bf0a666.