What I’m trying to do:
Open my app in the editor after trying out the new Faster Storage. I switched the app over to Faster Storage, set up indexing, and cloned the database. Not quite sure about the order. I clicked around a bit.
What I’ve tried and what’s not working:
The app will not open in the editor any more. It loads for a few seconds, then throws me back out to the My Apps screen, and two “An internal error occurred” dialogs come up one after the other.
It happens every time, and the error IDs are new on each attempt:
Attempt 1: 474781a3c4c2efc2 then 14856d9931d4f1b2
Attempt 2: d3fcdb71db62dcc0 then 8a3df68bb09ba44a
App ID: RKQQ7ZON53FRV6Q7
My other apps open normally, so it looks specific to this one. It is a work in progress app with no users and no important data, so feel free to poke at it directly.
I have enabled the new faster storage in data tables settings.
Attempting to clone a database and getting this error:
Any suggestions on how to resolve this?
(Could it be that I’m sharing tables between different apps?)
Created a brand new table, and just trying to write to it using the direct sql access but get the following error:
import anvil.tables
import psycopg2
conn = psycopg2.connect(anvil.tables.get_connection_string())
try:
with conn.cursor() as cur:
cur.execute(
"INSERT INTO test_table (my_idx) VALUES (%s)",
(1,),
)
conn.commit()
print("OK")
finally:
conn.close()
RESULT:
InsufficientPrivilege: permission denied for sequence table_1086374__id_seq
at <input>:7
called from /home/anvil/downlink/anvil_downlink_worker/__init__.py:320
called from /home/anvil/downlink/anvil_downlink_worker/__init__.py:366
called from /home/anvil/downlink/anvil/_threaded_server.py:191
app_tables.test_table.add_row(my_idx=1)
print("OK via app_tables")
RESULT:
OK via app_tables
Does this mean we cannot write to the faster storage tables using direct sql access?
@Neeeco: Looks like this is because you’re on a legacy Dedicated/ESR plan and we need to do a manual update on your instance to enable Faster Storage. We’ll get round to it and let you know when it’s done.
@jorn: That app is impressively broken. We’re still looking into it, but we’ve definitely got the error surrounded! We’ll keep you posted.
@jorn: Fixed! It was a corner-case bug in the interaction of legacy Dedicated databases and Split Tables. Ultimately didn’t corrupt any data but the validation routines prevented loading of your app in the IDE just in case.
@divyeshlakhotia & @Neeeco: Also fixed! This was an issue that affected cloning tables with a “dangling” link outside of your application under certain circumstances.
@Neeeco - can you please double-check whether your Direct SQL issue is still occurring? It’s possible what we’re seeing is crosstalk from the bug you and Divyesh saw…or it might be as we first thought and we need to update your ESR instance. Could you check please?
I can now clone that database that wasn’t working before, so that’s fixed.
Still cannot write using direct sql access, the same query still raises the same error. I did re-clone the database, added a new test_table but same permission error.
I have found a mismatch in the query results between the old and new tables storage. I cloned a database. In both cases I have 2 rows matching a specific client. The column that I’m interested in is called adjusted_history which is a simple object column.
One of the rows has a Python None value for the adjusted_history column, the other row has a dictionary in that column. On the old table running the query below returns a total of 1 row which is correct.
On the faster storage, the query below returns 2 rows. So the q.not_(None) is not behaving as expected.
