I got this error while working with Prisma, my solution is below.
I just want to post a solution, I don't have a question anymore. I need to keep typing this in order to meet Stack Overflow quality stnadards.
The issue was that my schema and database weren't up to date.
I added a field to my model, but didn't push/migrate it to my actual db.
The solution was to push/migrate the new schema to the database
Related
So I am using Postgres for my production database. I use Alembic for migrations and SQLAlchemy to define models and query and so on. This setup works very well for the most part, but I have run into a problem recently.
One of my tables requires a config column, which will be a json blob of varying contents. As such, I have opted for the Postgres JSONB type.
The issue is that my local tests run with an sqlite in memory database. Sqlite apparently has cannot interpret this column type, raising the following exception up running the tests (and building the database):
sqlalchemy.exc.CompileError: (in table 'applications', column 'config'): Compiler <sqlalchemy.dialects.sqlite.base.SQLiteTypeCompiler object at 0x109e52ef0> can't render element of type JSONB
Has anyone got a suggestion about how to overcome this issue? I was thought about maybe trying to alter the migrations based on whether the program is running tests or in production, but I really don't know where to start in that regard.
Has anyone got any advice?
Thanks in advance,
Eric
For anyone who comes across a similar issue: as mentioned in the comments on the question, Sqlite presents many differences from Postgres. As such, my testing environment does not mirror my production environment well and differences like these force me to consider hacks, which is bad news.
The solution I have chosen is to containerize a Postgres db to be spun up when tests are run as described here. It's a slight hit in terms of speed, but it does allow me to reliably test db behaviour locally and in CI pipelines, so I think it is worth it.
Thanks to all the people who took the time to comment.
I have searched for the answer on following question for a long time and didn't find anything except of restoring several tables. I have a directory based dump of postgresql database, what I want to do is perform restore of this database based on some data condition like: WHERE [SomeField] > 10. Is it possible? And if yes, could you please advice me how to do this? Thank you
I can run a query on views in SQL Developer 3.1.07 and it returns the results I expect. My co-worker, who is in Mexico using the same user, can connect to the same database, sees the same views, runs the same query and gets no results, even from a simple "select * from VIEWNAME" query. The column headers display, but no data. If he selects a view from the connections window and selects the DATA tab no data displays. This user does not have access to any tables on this specific database.
I'm not certain he is running the same version of Developer, but it's not far off. I have checked as many settings in SQL Developer that I think could be the issue, but see no significant difference in his settings from mine.
Connecting to another database allows him to access data in both tables and views
Any thoughts on what we're missing?
I know I'm a few years late, but check if the underlying view doesn't filter on something that is based on localisation! I just had the issue and it turned out to be a statment like this that was causing issues:
SELECT *
FROM sometable
WHERE language = userenv('LANG')
Copy the JDBC folder from your oracle home and copy it over to your c-workers machine. we had the same issue and replacing the JDBC folder worked.
Faced the same which got resolved when I checked the 'skip NLS settings' box. My query was returning zero results earlier but when I ran the same query again, I could see the table rows.
Since your co-worker is in a different country, most probably the NLS settings (related to the language) are the culprit here.
I was facing the same issue, turned out that the update to the database from my sqldevelolper was not commited to the main database, that's why, I was getting results on my sqldeveloper for that query, but from aws it was returning empty results. When I chatted with DBA, he could find stale data. After I committed the data from my sqldeveloper, the db was actually updated.
I have function that initialize my database create tables etc.
Now I prepare version two of the application and in this function at the end I added check for column existence and if not exist I alter table.
My question is:
To avoid checking this all the time is it good to put in UserDefaults some flag that indicate that current app is version two and if it is to avoid this code?
This seams logical to me but other opinion is always welcome ;)
You could have a version number table/column in your database which stores the schema version number. Every time you change the schema, increment the number in your application file and then run the relevant migration code to get from one schema version to another whilst updating the schema version in the database.
This answer has a handy way of tracking db schema version numbers without creating a separate table in SQLite
Yes, you can user NSUSER Default to check this. I don't think anything wrong with this.
I want to update my sqlite table through query:
UPDATE animals SET name = 'kangaroo' WHERE id = '9'
My query runs normally without error but my table was not updated so i checked the code returned by mysql_step() and it returns 5 which means my database is busy. I have used the database connection in many classes in my project. I also checked that i have closed the connection properly or not. Than why this database busy response is coming? Please help i spend a lot of time with this problem and was unable to sort out the solution...
Unfortunately I don't think there is going to be one simple answer, as there is no simple question. The update query is fine; as you suggest, it is the complexity of the relationships within the app which matter. You will have to break it down until it works, then build it back up carefully.