Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions Sources/eppo/AssignmentCache.swift
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,17 @@ public protocol AssignmentCache {
}

public struct AssignmentCacheKey {
var subjectKey: String
var flagKey: String
var allocationKey: String
var variationKey: String
public var subjectKey: String
public var flagKey: String
public var allocationKey: String
public var variationKey: String
Comment on lines +9 to +12
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this definition, it seems off? In a sense that it is not a real cache key (but rather a “cache entry”)—the user has to re-implement CacheKey/CacheValue which are still hidden and it may be rather tricky

If we want to make assignment cache public / implementable by users, I would argue that it should work on either CacheKey+CacheValue, or it should accept the whole assignment event (so users have the freedom of what they want to cache on). But at this point, it becomes rather rudimentary and it's probably easier for users to implement a wrapper around their own logger, which is rather easy to do

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're definitely right about that - ok before making this public I think it makes sense to tidy up the interface by splitting it out.


public init(subjectKey: String, flagKey: String, allocationKey: String, variationKey: String) {
self.subjectKey = subjectKey
self.flagKey = flagKey
self.allocationKey = allocationKey
self.variationKey = variationKey
}
}

public class InMemoryAssignmentCache: AssignmentCache {
Expand Down