How do I delete ContentTypes in Bolt.cm? - bolt-cms

I've just installed Bolt CMS and it offered to generate some sample content, which I did. So now there are 3 contenttypes: pages, entries, and showcases.
I want to keep the pages and entries but don't want the showcases. How do I remove them? I can remove the section from the contenttypes.yml file and they disappear from the front-end, but it still leaves the bolt_showcases table in the database, and also 'showcases' rows in other tables like bolt_taxonomy.
Do I need to delete all this manually? How do I make sure I've removed all traces of an old contenttype?

Contenttype records are limited to a single table. The only thing that escapes that boundary is taxonomy relationships.
To achieve what you want, delete the Showcase records in the UI, that will remove the relationships, if any, then you can safely drop the bolt_showcases table.

Related

Cache, Database, Over 400k Listing

In my MySQL database I have a table of products which contains almost 625k rows. The table has 162 columns.
Now there is a search box on my home page where you can search for anything and, if your search term is matched from any of my product titles, it give you a list of 15 products. This is similar to Amazon and other e-commerce websites.
What I did so far was to create a JSON file with all the product ID's and title names. When user inputs a minimum of 3 chars into the search field, an AJAX request is made and gets the list. But my issue is that the JSON file is almost 12MB in size, and the ajax calls it whenever user write's a char or removes a char. It was working fine until I was on local Machine and now as soon as I made it live it doesn't work for users, having lower then 5 MBPS internet connection. So I am looking for some advice, how do I create it fast as Amazon. I mean the search with auto suggestion from 625K products.
I am really sorry, but there is nothing more to give as an advice here then "go do some reading on database design and schema normalization".
If you have 162 columns in a table you will never be able to do an efficient search. The database (especially MySQL) will not hold the table in memory and indexes will not help either. Yes, you can throw it all into an ElasticSearch instance and it will fix some of your problems. But, honestly, this solution does not clean up the mess you have.
You should have a table with relevant information (titles, names, etc.) in one column (or also a numeric column for prices, etc). This metadata should reference the main table, the column should be fulltext-indexed. This way you ask for matches, filter results and JOIN relevant lines from the main table. This will work quickly with very little resources used.

User submitted content to mysql with moderation: separate table?

In an mysql table I would like to get data from user, however the data would need to be moderated by admin first. My question is that is it normal to just insert into the original table and use a field as flag of the moderation status? Or have a separate table of pre-moderated posts and do the insertions only at moderation?
I think both method would work but I am not sure if I miss out other considerations here. Hope someone experienced can tell me the established/preferred way to do that.
If you're working with a not-huge data set I'd recommend just adding a flag column that allows you to show or hide user data. This will require fewer and easier queries to work with and should make your life a lot easier than juggling the data between multiple identical tables. Additionally, if you want to add something like a button for "report this content as BAD" you could remove the content from other results while only "soft deleting" it from public visibility.

Best practice for enabling "undelete" for database entities?

This is for a CRM application using PHP/MySQL. Various entities like customer, contact, note, etc, can be "deleted" by the user. Rather than actually deleting the entity from the database, I just want it to appear deleted to the application, but be kept in the DB and able to be "restored" if needed at a later time. Maybe even add some kind of "recycle bin" to the app.
I've thought of several ways to do this:
Move the deleted entity to another table. (customer to customer_deleted)
Change an attribute on the entity. (enabled to false)
I'm sure there are other ways and that each have their own implications on DB size, performance, etc, I'm just wondering what's the generally recommended way to do something like this?
I would go a combination of both:
Set a flag deleted to true
Use a cronjob to move the entries after a while to a tabelle of type ARCHIVE
If you need to restore the entry, select into the article table and delete from Archive
Why i would go this way?
If a customer deleted the wrong one, the restore could be done instand
After a few weeks/month the article table may grow up to much, so i would archive all entries that are deleted for 1 week p.a.
A common practice is to set a deleted_at column to the date at which the entity was deleted by the user (defaults to null). You may also include a deleted_by column for marking who deleted it. Using some kind of deleted column makes FK relationships easier to work with since these wont break. By moving the row to a new table you would have to update FK (and then update them again if you ever undelete). The downside is that you have to ensure all your queries exclude deleted rows (where this wouldnt be a problem if you moved the row to a new table). Many ORM's make this filtering easier so it depends on what you are using.

Correct way to set up MySQL tables

I can't work out what I should be doing here...
I have a database with around 20,000 records. Each of these records has about 20 columns to it.
I want to add around 20 or so additional columns to this database which would be on the lines of a load of different URLs for each record. Mostly, these will be blank.
What's the "right" way of doing this:
Add 20 additional columns (youtubeurl, facebookurl, etc)
(Benefits: only one URL call // Drawbacks: makes my database much larger)
Add an additional table with three columns - 'ID','URLType','URL' which I can additionally call?
(Benefits: keeps main table much smaller // Drawbacks: additional SQL query required)
What should I be doing?
Everything else being equal, I would go with option (2). This allows you to keep your data normalized and offers flexibility if you need to add more sites in the future.
FWIW, this does not require an extra query to SELECT data, as you can just JOIN to the other table. But of course, it would require extra INSERT / UPDATE queries.
Option 2 is a almost certainly the better option. It makes it easier for you to add new Url types in the future (just invent a new URLType instead of having to create a new column). Pages that use these urls then don't have to be modified to accomodate the new type of URL; they'll just pick it out of the table. In other words, you only have to make a change in one place instead of several.
If people mostly have only a few of these urls, splitting it into a separate table is almost certainly the way to go.
Everything you're adding is a URL. Each URL is related to one (or maybe more) of your current records. So either:
for URLs that have only one record-
urls table with url and FK to records table
or for URLS that can relate to more than one record-
urls table with url_id and url
linking table with record_id and url_id

ms access can't edit field because I must delete relationships but there are no relationships to delete

I have built a database on multiple tables. One of these tables has a field (Initials) that was originally defined to have 50 characters. After building the entire thing I realize I would have liked that field to be limited to 3 characters. I tried to change this, but it tells me that I have to delete one or more relationships. So, I open up the relationship window and delete the one relationship that is attached to this field, expecting that I should be able to go back and change the character limit then go back and add the relationship again. So, as of now there are ABSOLUTELY NO relationships touching Initials in the relationships window. I go back to change the char limit and it gives me the same error. I can't even delete Initials and recreate it because of the same error. I went through my entire project and took that field out wherever it appeared. Still, same error. Any ideas?
Per Matt,
apparently when you display a field in a report it does not show up in the relationships >window. I deleted it from the report, edited the char limit, then put it back in the >project. of course, right when i resort to the forum i figure it out. thanks to those who >helped