I am using prisma with mariaDB whit in my application. The app does a lot of equal request to the database. However, sometimes i got from database records that are just being delete, multiple times. This got me thinking that prisma or mariaDB have some type of cache to resolve multiple equal queries. I want to disable that.
Any idea on how to approach this problem?
Related
I am working on a smaller project. I have two tables e.g. properties and agents. One property can have many agents. How can I update data in both tables using one query?
Here is the link to update data in postgres How I can update one to many relation in Postgres?
Supabase uses postgrest under the hood for the RESTful api, currently the suggested solution there is to write an rpc() function and call that.
Alternatively, since Supabase is just PostgreSQL, you always have the option of connecting directly using any postgres client and using the postgres solution you mentioned in your question.
I have to delete user data in a database used by a laravel/eloquent application. It can be done with some SQL queries.
Problem: I have no clue of laravel/eloquent. That's where I need your help.
Is it safe to bypass laravel/eloquent and just change/delete data in the database using SQL queries (manually or with a script)?
With the assurance provided in the comments of my original question I deleted the data using some SQL statements, executed by the phpMyAdmin SQL feature.
Everything worked as expected.
Of course I studied the data model, backuped everything, and run tests on a copy of the database before performing the change on the production system.
Whenever I am inserting a key in any one db of the redis cache, it gets inserted in all 16 dbs and removing the key from any one db deletes the same from all DBs. Attached is the screen shot showing the same. As per my knowledge, the DBs are independent of each other and at a time any key should be inserted/removed from the current DB in use. Could anyone please explain the observed behaviour?
The Azure Redis Portal Console currently doesn't handle the Select statement correctly (because each command goes out on a new connection), so you are actually doing a get on DB 0. This is a known issue and we are in the process of creating the V2 of the portal console, which will fix this issue. Rough ETA is sometime in the next couple of months.
I am new to using Laravel, and I'm currently learning about Laravel's database migration and seeding features.
It's working with the command prompt, but I can migrate and seed in phpMyAdmin as well. What are the advantages and disadvantages of migrating and seeding within Laravel as opposed to phpMyAdmin?
From Laravel docs on Migrations & Seeding:
Migrations are a type of version control for your database. They allow a team to modify the database schema and stay up to date on the current schema state.
A simple search for why database migration also gives me some pretty decent results. One of the easiest to understand is a page by FlywayDB (I have no idea who they are until I search this term up):
Database migrations are a great way to regain control of this mess. They allow you to:
Recreate a database from scratch
Make it clear at all times what state a database is in
Migrate in a deterministic way from your current version of the database to a newer one
The illustration they made perhaps explain it more clearly, so you may want to check it out.
I'm learning laravel and in most of tutorials they are making migrations using artisan.
I skip that step and I'm working directly on a database.
I don't know for what can a migration be useful.
so the question is: what is exactly a migration?
If you are the lone developer, you may not get much use out of it.
But imagine you have multiple developers each with your app stored locally on their machine. What happens when you need to make an update to the database? You would have to make the update, send the query to each other developer, and they would have to run the query on their machines. Once you get a decent amount of developers making changes to the database, this process can quickly become overwhelming and it's only a matter of time before people start missing the changes.
With migrations, all of the changes are stored as files, so in order for a developer to catch up, all they need to do is fetch the code changes and run php artisan migrate and all the work is done for them. This means all your developers are consistently working with the same database structure.