Roadmap

SHOULD: Short-to-Medium-Term Plans for Expected Functionality

• ✔️ Deploy version 1.0.0 to Maven Central using GitHub Actions. 1-2 weeks after initial commit => Done, 28 December 2023
• ⏳ Regularly run repository-ydb-v2 integration tests using GitHub Actions. 1-2 weeks after initial commit => #6
• ✔️ Support Kotlin dataclasses in StdReflector. 2-4 weeks after initial commit => Done, #7
• ⏳ JsonConverter implementations for popular JSON libraries: Jackson, Google Gson/Square Moshi. 2-4 weeks after initial commit
• Add JavaDoc to all public classes, document unstable APIs with Guava's @Beta annotation or something similar. Add an explicit versioning policy (recent SemVer?) + document the first library version it applies to. 1-2 months after initial commit
• ⏳ Change outdated and/or deprecated data binding defaults, while supporting older defaults for backwards compatibility. => #20
• ⏳ Stricter ReflectType for POJOs. Remove deprecated logic for all-args constructor detection which relies on e.g. Class.getDeclaredFields() being in a predictable order => #19
• Use common timestamp and interval (Instant and Duration) data binding logic in both YdbRepository and InMemoryRepository. Support qualifiers for these types in InMemoryRepository, for more precise tests. 1-2 months after initial commit
• Support GROUP BY in YqlStatementPart and query() DSL (TableQueryBuilder). 1-2 months after initial commit
• Add row-limit-aware upserts and selects (never causing ResultTruncatedException); the row limit must be configurable if YDB [still] has no API to get the actual limit value. 1-2 months after initial commit
• Translate all code comments to English, and actualize them if needed. See e.g. YdbValidator. 1-2 months after initial commit
• Deprecate LegacyYdbSpliterator and ReadTableParams.useNewSpliterator() for removal; then remove them permanently in a minor release. 1-2 months after initial commit
• Actualize YOJ dependencies, use latest minor versions of everything. 1-2 months after initial commit
  • Maybe add Dependabot to our repository?
  • Maybe use SLF4J 2.x?
• Overhaul nullability annotations in YOJ. 3-4 months after initial commit
  • Ideally, we should have minimum annotations, assuming non-null parameters and return values by default, with nullable parameters and results being annotated with @Nulable. Want to use @ParametersAreNonnullByDefault, @CheckForNull, and sometimes @Nullable annotations.
  • If the "ideal" plan doesn't work with IntelliJ IDEA at least, add missing @NonNull annotations (there will be lots of them 😢).
  • Should we use Lombok's @NonNull annotations to have requireNonNull() code generated for us? I think yes.
• Remove unsafe methods from Table (blind upserts and deletes), have a separate interface for them to force users to write e.g. db.myTable().unsafe().blindDelete(...). 3-4 months after initial commit
• Deprecate Changeset for removal, or, alternatively, move it to unsafe().blindSetField(). 3-4 months after initial commit
• Deprecate and remove static configuration. Move such configuration to type and field annotations, or SchemaRegistry if that is not possible. This will allow to have multiple differently configured ORM instances inside a single JVM, for much easier component and integration testing. 3-6 months after initial commit
  • ⌛ FieldValueType.registerStringValueType() => #24
  • Kikimr{Schema,Data}CompatibilityChecker (and, way more importantly, InMemoryTable and YdbTable and YqlStatement) do not take a SchemaRegistry and implicitly depend on the default one
  • Move CommonConverters+JsonConverter.{define,disable}JsonConverter to use SchemaRegistry, maybe?
• Overhaul magic ID field naming logic, and custom naming logic in general: NamingStrategy currently has a void which calls deprecated JavaField.setName() method to define column names. Maybe rewrite it to use builders or something like that :-). 3-6 months after initial commit
• Fix data migration problem: older client reads newer version of the entity, changes it and saves it; but columns unknown to the older client are not set to NULL and remain as-is, potentially violating data invariants in the newer clients. Try to use REPLACE for this. 6-8 months after initial commit
• Get rid of repository-ydb-v1. 6-12 months after initial commit

MAY: Nice to have. We might do this some day, but this is in no way guaranteed

• Asynchronous and/or reactive API (YDB SDK uses CompletableFutures underneath, so this is doable, just painful.) :-)
• Stricter code style and Checkstyle rules to enforce it
• Minimize library dependencies
  • Apache Commons Text is used essentially in one place (compatibility checker), is it even really necessary?
  • Do we need Google Guava? Can we live without it?
• Quick Start Documentation
• Code Reference
• Code Samples