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

v2: minor changes but breaking #35

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

v2: minor changes but breaking #35

wants to merge 4 commits into from

Conversation

abraithwaite
Copy link
Owner

switch from tinylib/msgp to github.com/vmihailenco/msgpack/v5 as it's more flexible and doesn't require codegen. Might be a bit slower since it uses reflection? Haven't tested performance.

Use store arbitrary metadata as something which can be serialized and deserialized to and from the Sessions struct. Might unexport the Meta struct. Almost went with generics, but found the serialization pattern to be more digestible.

switch from tinylib/msgp to github.com/vmihailenco/msgpack/v5 as it's
more flexible and doesn't require codegen.  Might be a bit slower since
it uses reflection?  Haven't tested performance.

Use store arbitrary metadata as something which can be serialized and
deserialized to and from the Sessions struct.  Might unexport the Meta
struct
Thought a lot about this change.  Want to be able to support standard
SQL backend database engines (BYO SQL database session plugins) and what
I realized I want most from that is structured data in my sessions table.
That structured data may be out of scope for the other KV stores: e.g.
last active IP / location would not be as easily usable in a KV
datastore.

Between []bytes and the any type, there wasn't really a good option that
didn't involve either using reflection or serialization.  Therefore I
decided it would be better to fallback to KV pairs.  I will play around
with this a bit to decide which format works better: a slice of kv pairs
(probably more efficient) or a map (more naturally usable).  I could
(may still) make the underlying slice/map unexported to support swapping
between them for ease-of-maintainability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant