-
Notifications
You must be signed in to change notification settings - Fork 403
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
Migrate hive to dart nnbd #521
Conversation
* Using `dart migrate`
* Will be needed for mock codegen
* Also add missing imports and remove duplicated methods and accessors * The codegen was made with an modified build of dart-lang/mockito@c387e34 that adds an `as $Type` after each noSuchMethod invocation to fix the static type error of returning dynamic instead of the correct type
* Because every element is of type E, and E extends HiveObject, the type E can never be nullable, and therefore no element can be null, otherwise an static type error would happen, so the check would always pass
* MockHiveObject does not need to exist, i shouldve used an TestHiveObject which extends HiveObject. * So, create the class, use it in the tests and remove HiveObject from the GenerateMocks annotation.
* Remove the MockHiveObject class
* The null check operator needed to be inside an ${} block on the concatenation, so because it wasn't, it was interpreted as an '!' String. * I did not use it now because both Object and Object? have the toString method, and althogh an invalid path would be generated in case path was null, this will never happen, because of the ArgumentError.nonNull on the start of the functions.
* hashCode, == and toString are used internally in Maps, Sets, and other places of the dart standard libray, and returning null is not allowed, therefore, the functionality gets broken. * As we do not mock any of these, using the standard Mock implementation is fine, as it does not return null. * This is NOT ideal, something should be done once the non-nullable Mockito api and codegen get stablized.
* It was accidentally removed on the migration
* registry is an non-nullable late property, and it is set on StorageBackendVM.initialize, but we do not call it on the read/write tests, therefore they throw, so to fix it, we manually set the registry before the read/write tests.
Tests for the codegen are looking good. Didn't find an problem reviewing it manually, and |
* BinaryWriter contains the correct nullability, but BinaryWriterImpl was wrong
@themisir soo, only hive_flutter remains to be migrated, and the current version for it is 0.3.1, and according to dart.dev, the new version can either be 0.4.0-nullsafety.0 or 1.0.0-nullsafety.0. which one will we go with? The same for hive_generator, which is 0.8.2 and can be either 0.9.0-nullsafety.0 or 1.0.0-nullsafety.0. And, should we finish reviewing and publishing the core packages (hive and hive_generator) before migrating hive_flutter, or should i migrate it in this PR? Im waiting for further instructions so we can move hive forward! |
I think increasing major version (1.X.Y+nullsafety.Z) will work for us cause the new library will not be compatible with previous version because it requires explicitly enabling NNBD. Correct me if I'm wrong. And about Also I have a question. I haven't worked on null-safety enabled projects before so, will the NNBD version work with the previous versions of the flutter or dart? I mean at least currently stable versions (which comes with NNBD disabled). Or we'll have to maintain nndb and non-nndb codebase separately? (I've inspected some of flutter's own source code on my localhost, currently my flutter environment set to not use NNBD but flutter source code contains NNDB code.) If you have any idea about that please let me know. 🙏 |
I would recommend
It would be great if nullsafety releases could be published as soon as possible for |
After testing these changes I think I've found a bug in I would expect the following to be valid: Hive.init(path);
await Hive.close();
Hive.init(path); // this throws HiveError: Instance has already been initialized.
await Hive.close(); This could be solved by resetting the @override
Future<void> close() {
var closeFutures = _boxes.values.map((box) {
return box.close();
});
homePath = null;
return Future.wait(closeFutures);
} Another option would be to revert 59ad540#r46404472 as it introduces a breaking change and no longer allows for multiple Hive instances to exist simultaneously. Let me know what you think 👍 |
Initializing hive multiple times causes weird errors. So Instead of initializing it multiple times you can construct var hive1 = HiveImpl();
hive1.init(path);
await hive1.close();
var hive2 = HiveImpl();
hive2.init(path);
await hive2.close(); |
@themisir thanks for the clarification! Is there anything blocking a release of |
Alright, thanks for the tip! I will promptly update the versions and write a changelog for the packages.
I think there isn't, the tests are passing, including the integration tests, and the hive_generator code looks good, but i haven't tested the new hive manually in an real enviroment. If you could, that would be of great help, ensuring that it can be merged safely, otherwise i can do it after the deadline im in. I'm sorry for the late response, these days i've been busy with an deadline for 02/01, so i haven't had the time to follow up this pr. |
@themisir no problem I completely understand! I’ve upgraded hydrated_bloc to use this version and everything seems to be working 👍 |
I'll work on this pr today. And publish if everything goes okay. |
* also write the tiny changelog
* The generator does not depend on changes made on package:hive
* Preparing for publishing
* prevents the list from having to grow possibly many times
* These primitives must not be null. To write an null value, use write.
I've just completed testing @KalilDev can you upgrade minor version instead of major as @felangel said? I'll merge this PR after that.
|
I just pushed hive_generator to 0.9.0-nullsafety.0, here, is there anything else left? |
Can you also set |
Nevermind I'll do it myself after merging. Thanks for the contribution 🙏 |
Oh, sorry, i had to leave home for a bit.
Alright!! No problem, man! Thanks for merging! |
No problem ✌ |
@KalilDev may I know how did you setup your environment (flutter cli, vscode, etc...) to use null safety? I couldn't setup mine unfortunately :( |
For it to work I'm using vscode as the ide, and it didn't need any special configuration, and for using nnbd hive on a package, the dart sdk constraint needs to be >= 2.12.0-0 and the hive dependency needs to be overriden with the following pubspec entries:
|
For now, package:hive was migrated, and every test passes, but there are some hacks on the test's codegen and package:crypto and package:mockito have been overriden with git versions which were not published on pub.dev. The tests also depend on the legacy package:dartx and package:pointycastle, so they can only be ran with --no-sound-null-safety.
The release is blocked until at least package:crypto has an published non-nullable version.
Ill start working on the hive_generator, as hive needed to be migrated first because it is an direct dependency of the packages which would use the generator.