-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure to create core shouldn't raise an exception. #69
Comments
I think the However, I'm getting a related error, even when I set I checked my params at this point in the call stack, and they looked good: https://github.com/cbeer/solr_wrapper/blob/v0.21.0/lib/solr_wrapper/instance.rb#L152 One step deeper, I found that both calls to In my case, I'm not in cloud mode, so the method of interest is So I'm wondering if that value in the response means the core is missing, or not? Note that the first time of running |
Followed up with a more detailed ticket in #92. Might supersede this one? |
I'm having problems with this in Hyrax 1.0.0.rc1. Running:
... results in the same error above:
Have tried setting persist: true but to no avail. Is there a CLI workaround? I'm very new to all of this! EDIT: have found a "rake solr:clean" resolves this. We're now looking at pointing the Hyrax gem to our own installations of Solr and Fedora4 so we don't need the "rake hydra:server" command... |
I believe this is getting in my way too. Anyone have any insight in the past two years? |
My insight is that I've been using To me the most egregious part isn't whether I get the (incorrect) exception message, as is the crux of this ticket, though that does indeed happen. It's that the existing core is successfully deleted before I can do anything about it, with the exception message mentioned here then being output as well, and Solr fails to start. Thought it will start the following time, only the core is gone. So I would describe the problem more like #82 mentioned above, except with the core you need getting trashed into the bargain. I think this affects me more than most, as I tend to hoard content in my development environment and, with the "double reindex of everything" required to get Hyrax/Samvera apps back working as expected, it has taken me the best part of a day to recreate my index in the past. So what I do is go in and edit this line in my local gem, such that it always obeys the user "persist" request. Persist should trump "destroy and recreate", especially when the existence check cannot be trusted! In other words I leave the rest of that line commented out the whole time for working on my main project: And I live quite happily like that until I get a new machine or update this gem and get reminded of the issue. Thoughts
|
Should we trap for this error in
with_collection
and just log it?The text was updated successfully, but these errors were encountered: