Skip to content
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

Merged
merged 8 commits into from
Oct 31, 2020
Merged

Hotfix/2.8.1 #13

merged 8 commits into from
Oct 31, 2020

Conversation

bmeike
Copy link
Contributor

@bmeike bmeike commented Oct 28, 2020

There are two commits here:

  1. This is the change that is driving 2.8.1: backward compatible default db directory. This is the only code change in the product.
  2. Fix the packaging for Java. We had to do this by hand, in the 2.8.0 release. This puts the support libraries into separate directories, by category

@@ -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());
Copy link
Contributor

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)?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

@bmeike bmeike Oct 28, 2020

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.

@bmeike bmeike requested review from pasin and borrrden October 30, 2020 17:21
// 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; }
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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());
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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,

  1. The partial copy will be rollbacked which mean delete.
  2. The exception will be thrown.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

@bmeike bmeike requested a review from pasin October 30, 2020 18:47
Copy link
Member

@borrrden borrrden left a 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.

@bmeike
Copy link
Contributor Author

bmeike commented Oct 31, 2020

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:

  1. open a db that exists in the 2.8.1/2.x<8 default directory. This is probably redundant. FWIW, it would not have caught the original bug
  2. open a db that exists only in the 2.8.0 default directory
  3. open a db when both # 1 and # 2 exist: the one in the 2.8.1/2.x<8 directory is preferred.
  4. like # 2, except the copy fails: The 2.8.0 db remains. The 2.8.1/2.x<7 copy is deleted. An exception is thrown.
  5. like # 2 but the database is encrypted.

@bmeike
Copy link
Contributor Author

bmeike commented Oct 31, 2020

Since this is urgent and since I've changed only test code, since approvals, I'm merging this

@bmeike bmeike merged commit 8686d96 into android/release/hydrogen Oct 31, 2020
@bmeike bmeike deleted the hotfix/2.8.1 branch November 4, 2020 00:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants