-
Notifications
You must be signed in to change notification settings - Fork 6
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
Hotfix/2.8.1 #13
Hotfix/2.8.1 #13
Conversation
@@ -143,7 +141,7 @@ public static Context getContext() { | |||
@NonNull | |||
public static String makeDbPath(@Nullable String rootDir) { | |||
requireInit("Can't create DB path"); | |||
return verifyDir((rootDir != null) ? new File(rootDir) : new File(getContext().getFilesDir(), DB_DIR_NAME)); | |||
return verifyDir((rootDir != null) ? new File(rootDir) : getContext().getFilesDir()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code before fixing and the code after fix could produce different db path. Is this backward compat with 2.8.0 (e.g. app that is used 2.8.0 without using 2.7.0 before)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not backwards compatible with 2.8.0. It is compatible with 2.7.x.
If we have to make it compatible with 2.8.0 -- not an unreasonable suggestion -- we should keep the new directory an locate and copy existing dbs. This seems like pretty big change to me. Again, though, not unreasonable. I think a better suggestion would be to get this out quickly and to advise people not to use 2.8.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. We should make sure to put this into the release note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is unlisting 2.8.0 an option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. That is a discussion we need to have. I don't think there is a way to be 100% backwards compatible. The most common case for 2.8.1 is going to be that there are two dbs with identical names one in the root directory, one is .couchbase. Deciding which to keep probably requires direct human intervention.
rm -f "${SUPPORT_DIR}/libicu/"libicutest* | ||
|
||
mkdir "${SUPPORT_DIR}/libz" | ||
mv -f lib/libz*.so* "${SUPPORT_DIR}/libz" || true # Only on CentOS6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember that there is one .a copied to the support directory as well. Will this fix exclude copying .a file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good memory! Yes. The only .a is libz.a, so the pattern libz*.so* will not pick it up.
// directory and leave well enough alone. | ||
// It is *always* possible to use 2.8 database, by specifying | ||
// its directory explicitly. | ||
if (exists(dbName, defaultDir)) { return; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be a good to put some log here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! What would you like logged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I take this back. I think this is normal case not error case so no need to log. Sorry for confusion.
|
||
// This database is in the 2.8 default dir but not in the real | ||
// default dir. Copy it to where it belongs. | ||
Database.copy(getDatabaseFile(twoDotEightDefaultDir, dbName), dbName, new DatabaseConfiguration()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this operation failed, can we also rollback the partial copy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. So delete the copy if the operation fails. Then we will create a new DB and the data in the old db will still be there. Is that what you want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is what I mean,
- The partial copy will be rollbacked which mean delete.
- The exception will be thrown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. If copying the database fails, I will delete the partial copy and throw an exception.
That means that any subsequent attempt to open the DB will also throw an exception... the application now has a poison pill. Ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The upgrade / migration process always has some corner cases that I hope those will not happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see a test for this. Looks like it can be simulated by creating things by specifying the "wrong" default directory and then viewing what happens when a database is created using no specified directory.
Yeah. I'm with you. There was consensus that "blake should do nothing [no tests]" but the number of errors in the fix and the likelihood that QE will be able to figure out how to drive all of these cases convince me that they need to be there. There are now tests for the following conditions:
|
Since this is urgent and since I've changed only test code, since approvals, I'm merging this |
There are two commits here: