Squidex content stuck in MongoDb and is not shown on UI.
Squdiex content is marked as deleted and continue to be stored in MongoDb.
Squidex content stuck in MongoDb after Squidex App deletion and recreation with same name.
I’m confussed what happens in Squidex’s MongoDb.
Expected behavior
I want to find a and read Squidex Content records [by a schema] in MongoDb.
I want to understand can I safe delete all Squidex secondary content from MongoDb manually.
And what is safe to delete at all.
Out of scope
Find and delete schemas from MongoDB.
Environment
App Name:
[x] Self hosted with docker
Version:7.0+
Others:
Main topic question - interfering Squidex MongoDB, in order to fix and debug issues that are not fixeble from outside anymore by API/Squidex Library/Squidex UI. And I believe only direct manual deletion from DB can help me.
Thanks ahead.
In general Squidex has a no-deletion policy. Storage is very cheap and 99% of the users do not use Squidex for large data. So it does not matter if there is some data that is not deleted.
This sounds like a bug then.
Also falls under the non-deletion policy, but you can delete content permanently, if you use the correct flag.
Ok, thanks, something become a bit more clear.
Read some additional topics here.
Secondary content is data that is populated into schemas and displayed from Squidex UI Content tab.
So deleting it should not break anything in squidex.
There also is an issue with content stuck in DB and is not shown in UI, for example by reason of deleting schema without content first.
When content with this Id is re-populated - a 409 error occur - existing item with Id.
And deleting squidex app is used to work around this issue, but once it didn’t work for me.
So obvious solution is to try delete conflict items manually.
And, seems I found a topic that talks about this.
It’s saying that it’s possible to delete problem records from ContentCollection, or to use a trick with contents flags?
Is it safe enough to delete documents from ContentCollection? Like a secodary data that won’t break squidex main functionality?
The “problem” is how Ids are built. Before custom IDs, a content Id was always unique. So it was just a guid like b0d55162-9d03-4f0c-977f-055cc97bf543, but with custom IDs a Id is not unique anymore, so it needs to be prefixed with something.
I have chosen top use the app ID only, so a custom ID is something like b0d55162-9d03-4f0c-977f-055cc97bf543--YOUR_ID. The reason is that IDs cannot become too long and adding the schema ID as well would create Ids like d6cc5344-d02f-4420-bc53-0e818548060a--d6cc5344-d02f-4420-bc53-0e818548060a--YOUR_ID. Therefore an ID in one schema also blocks IDs in other schemas. I will add that to the documentation.
But you can delete an item again permanently, even if it already soft deleted using the API. You can even query with isDelete eq true. I recommend not to use the DB for that, because a content item exists in more than one place.
