Hello
We did the upgrde from 12.10.4 to 12.10.11
To do it I stopped the tomcat, removed the solr folder (we used an embedded solr) and then deployed the war.
It restarted well in 12.10.11 but every like was lost …
Where and how theses like are stored ? How could I bring them back ? Rollback database and war to xwiki 12.10.4 ? Also rollback my /data/xwiki/solr folder ?? ( the folder containing events/ extension_index/ filestore/ ratings/ search/ solr.xml )
Thanks,
Regards
Hi again
I found the issue
all the like was stored in our folder /data/xwiki/solr/ratings …
I don’t know why like are stored directly in Solr and not in the database. I was not aware of that. We will change our upgrade process to not clean solr folder anymore.
Restoring the /ratings folder should be enought.
Regards
Hi,
yes likes (and ratings if you’re using the Rating extension) are stored in Solr for better scalability.
Note that since XWiki 12.4 the events are also stored in Solr for better performance in the notifications: we kept the storage of events in the database for backward compatibility reason, but this might change next cycle (in 2023). So better be careful when removing solr folder in the future.
Note: Doc at https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HPermanentDirectory
Lucene (which is used by Solr internally) does not support migrating indexes after more than one major upgrade, therefore it might be better to not to rely solely on Solr for storing data, see java - Using Solr search index as a database - is this "wrong"? - Stack Overflow and [LUCENE-9127] index migration from 7 to 8 failing - ASF JIRA, and I think XWiki should be prepared to re-create all Solr indexes from other data after an upgrade. Therefore, I think it is a bug that data is lost after removing Solr indexes - or is this another storage format that is not an index?
Thanks for answer 
Unfortunately after restoring the rating folder we now have a lot of checksum issue, we are in a broken state
This is displayed on every wiki pages in place of the “like” button
I don’t really know how to restore properly just the like it’s not human readable folder 
I agree with michael. It sound a bad practice to store data in Solr, it’s supposed to be an index that we can reconstruct. It will made our futur migration and potential backup really painfull because the reason why we are removing solr on upgrade is because solr folder was causing trouble during previous upgrade for us. If it’s still time to change the direction take from 12.4 and also the Like feature, I really think it should be putting out of solr …
We fixed our issues and get back our likes by fouding a not corrupted backup of the “ratings” folder. Our wiki is now fully operationnal again. At the end we removed the solr folder, we regenerate a fresh one by starting the tomcat. Then stopping the tomcat again and just replace the “ratings” folder with our backup. Maybe this procedure will help someone else one day.
We are using a lot the like feature, we implemented some kind of “favorite” wiki space around it and an easy access to theses favorites for the user on their homepage.
So we are a bit worried about futur upgrade to major version of XWiki we can’t lost theses data and having to care about preserving solr data will potentially complexify the upgrade of the platform and issues that we can encounter. We are also using embedded solr so far, and if one day we decide to switch to separate solr server I hope it won’t be too much complex to keep likes.
We hopes that maybe an other solution will be find for Likes, I understand the need of improving performance by having a quick access to solr, but imo it should be just a 2nd layer, maybe Likes should be XWiki object in the db like every xwiki object with cache/solr as 2nd layer.
Anyway, I thank the XWiki team, always quick and usefull answer when we encounter an issue and a very active project and core team which is really appreciable in an open source project. We integrate a lot of opensource project in our solution and XWiki (with Keycloak) are by far the most serious and efficient team.
Regards.