I run a blog where the community can post time-sensitive community links (sports scores and such). After a certain time, those posts are no longer useful, so I want to delete them in batch via a MySQL query, but I don't know how. I imagine that getting rid of those posts entirely is more than just deleting from the wp_posts table, right? There other tables at work per post, aren't there?
I've tried a couple of auto- or batch-delete plugins, but they don't work half the time.
Please, could you provide a MySQL query to delete posts and their pieces older than X days from all relevant tables?
Thank you in advance.
--Nick
Wordpress has published its database structure in its Codex. Find out more.
Related
Hello expert I am working in banking software vendor company and we are working in PostgreSQL database due to load of work in office time(pick hour) I want to execute some function in specified time(off hour) with trigger. So please if you have any idea please help me.
A trigger should always be something fast. You don't want to hold transactions open for a couple of hours, that would be a really bad idea.
The correct solution for such a problem would be a queue. There are some existing implementations like PGQ, but I don't know if the'll meet your requirements.
I come to solicit your help after several days of research.
I have a PrestaShop 1.6.1.4 (multishop). This shop is connected with an ERP for manage orders and customers.
For each customers, we have multi-groups. The default group on my databse is 3 (customers).
My problem : Several times a day, my database auto-update and change my default-group by another value for all customers. On my shop, my customers have to be on "customers" group to use search engine and order... This is a real problem !
Someone can help me ?
Thanks a lot !
You should look for some module or custom function, probable related with ERP integration. This should be the cause of group modification.
Anyway, a complete update of all your customers default group should include 3 keywords you can find in your source code: update, customer and id_default_group. So, if you can find a PHP or MySQL sentence that combine this 3 keywords you will find the problem. But, is this is part of an ERP integration you should be careful deleting of commenting this code because it can cause a malfunctioning of your integration.
Good luck.
I'm new to socialEngine and a client of mine asked me to modify his website which is using socialEngine. He is using this CMS for over 6 years now and since then, it has never been modified.
I'm trying to reduce the size of database tables which are really huge.
For example,
the whole db is around 2G,
engine4_user_logins is 435MiB,
engine4_user_fields_search is 615MiB and
engine4_authorization_allow is 234MiB.
I searched for socialEngine db structure but I couldn't find it. I'm not asking you to explain every single table in database. My questions are:
Is it safe to empty these tables? And why are these tables so full?! Is it because of the long time that no modification applied to them?!
It's safe to clear engine4_user_logins however that data in that table is used in statistics section in SocialEngine's admin panel. You can clear it but you'll loose stats data. Don't clear the other two tables. SE uses
engine4_authorization_allow for item permissions and engine4_user_fields_search for searching.
engine4_authorization_allow and engine4_user_fields_search get populated when items are created in SocialEngine. blogs, users, groups, photos, etc. That's why they're huge.
If client is having performance issues, I suggest tweaking server configurations or upgrading the server.
I'm looking for the best solution to store the ettings for a website, like the limit of posts for users, limit of users online, ranks, min. number of posts to be able to do something.
Like here, if you're new you can't thumbs up/down a post, or whatever, so how would you store all of these?
I thought of creating a table with constants in mysql but i think it's not the best solution to add a new mysql query on every page refresh.
Why not? After all, MySQL can handle a large number of requests and I've seen much more complex queries than checking access rights. A MySQL query is a query to a file just like checking an INI file, but optimized. I'm guessing that if you don't expect a huge amount of traffic, you'll be fine with a database.
Here it's a matter of preference. I prefer to do this in MySQL because I don't like to parse files and find querying a database easier. Also, editing rows is easier than changing values in a text file.
I'd say your first thought was spot-on. Put constants into a database.
Has anyone had luck with removing large amount of issues from a jira database instead of using the frontend? Deleting 60000 issues with the bulktools is not really feasible.
Last time I tried it, the jira went nuts because of its own way of doing indexes.
How about doing a backup to xml, editing the xml, and reimporting?
We got gutsy and did a truncate on the jiraissues table and then use the rebuild index feature on the frontend. It looks like it's working!
This is old, but I see that this question was just edited recently, so to chime in:
Writing directly to the JIRA database is problematic. The reindex feature suggested in the Oct 14 08 answer just rebuilds the Lucene index, so it is unlikely to clean up everything that needs to be cleaned up from the database on a modern JIRA instance. Off the top of my head, this will probably leave data lying around in the following tables, among others:
custom field data (customfieldvalue table)
issue links (issuelink table)
versions and components (nodeassociation table, which contains other stuff too, so be careful!)
remote issue links or wiki mentions (remotelink table)
If one has already done such a manual delete on production, it's always a good idea to run the database integrity checker (YOURJIRAURL/secure/admin/IntegrityChecker!default.jspa) to make sure that nothing got seriously broken.
Fast forwarding to 2014, the best solution is to write a quick shell script that uses the REST API to delete all of the required issues. (The JIRA CLI plugin is usually a good option for automating certain types of tasks too, but as far as I can tell, it does not currently support the deletion of issues, so the REST API is your best bet.)