RUMM-2203 Use unique data directory for each instance of the SDK#906
Conversation
454ffda to
9fcd11a
Compare
| /// The list of deprecated paths from previous versions of this feature. It is used to perform cleanup. | ||
| /// These paths must be relative to the known OS location (`/Library/Caches/`) containing core directories for different instances of the SDK. | ||
| let deprecated: [String] |
There was a problem hiding this comment.
@maxep When writing this comment I realised that we cannot ship V1's data deprecation as part of V2 SDK. Because V1 uses single folder, the V2 SDK cannot know if particular com.datadoghq.<feature> folder corresponds to this or foreign installation. Think: a vendor SDK installed in an app where both use Datadog SDK but vendor uses V2 and app is on V1.
What we can do instead is having this deprecated paths work the same as authorised and unauthorized - meaning they will be applied relatively to the SDK "core directory". It implies no need for this configuration now, but we could eventually leverage it later. We could remove this setup for now, or keep it empty.
WDYT?
There was a problem hiding this comment.
a vendor SDK installed in an app where both use Datadog SDK but vendor uses V2 and app is on V1
If both versions mismatch, the app won't be able to install the vendor framework as a dependency, except if the vendor is manually linking the Datadog SDK as a static lib, which should be discouraged IMO. The app would have to upgrade to v2 or use a previous version of the vendor SDK to match the version. So I wouldn't consider this use case.
Now, multiple instances of the v2 SDK will perform the same operation on the deprecated v1 directories, so I wonder if this is the right place for v1 depreciation 🤔 We can consider this as a temporary measure and eventually remove this deprecated when we consider good adoption for v2 (which can take time..)
There was a problem hiding this comment.
👍 Right, I think it's fair to assume there will be a single version of the SDK even if multiple instances are enabled.
Indeed, there's a room for improvement around deprecation logic. Because it requires more refactoring in different parts of the codebase, I created RUMM-2312 to focus solely on data deprecation logic. For now, I'll keep it as it is - capable of removing global SDK folders, without ensuring the logic is ran only once.
maxep
left a comment
maxep
left a comment
There was a problem hiding this comment.
Nice work with the hash for identifying core instances 👍
LGTM ✅
2 participants
What and why?
📦 With this PR, each instance of
DatadogCorewill use a different directory for managing its data.This is a step forward towards V2 architecture, where we're going to support multiple SDK instances. Each instance of the SDK needs to persist data in different locations.
This is the content of
/Library/Caches/when using two instances ofDatadogCore:How?
Each
DatadogCorenow accepts a "core directory". I introduced a separateCoreDirectorytype that wrapsDirectory- this is to enforce type safety at configuration level and to avoid passing wrong directory by mistake.The
CoreDirectorycreates the folder structure for SDK and its Features. It uses a hash function (sha256) for computing the folder name that is unique for given instance of the SDK:Review checklist
Custom CI job configuration (optional)