Skip to content
This repository has been archived by the owner on Jul 8, 2024. It is now read-only.

Add Filename option to hashmap driver to save to local file #26

Merged
merged 2 commits into from
May 25, 2023

Conversation

calvinmclean
Copy link
Contributor

Description

Add Filename to hashmap.Config to optionally store data in a YAML or JSON file. This can be useful to run simple applications locally with the option to easily scale to another database backend.

I was originally going to add as a separate driver package, but I realized it would mostly be copy/paste of the hashmap implementation so I combined it using an optional config value. Let me know if it would be better to move into a separate package.

In order to marshal data to YAML, I added the ByteSlice type to implement custom Marshal and Unmarshal. The default Marshal would write a []byte like an integer array:

key:
  - 118
  - 97
  - 108
  - 117
  - 101

With the ByteSlice, it is:

key: value

@codecov
Copy link

codecov bot commented May 24, 2023

Codecov Report

Merging #26 (8d6f0a5) into main (44b7826) will decrease coverage by 1.18%.
The diff coverage is 78.87%.

@@            Coverage Diff             @@
##             main      #26      +/-   ##
==========================================
- Coverage   91.16%   89.98%   -1.18%     
==========================================
  Files           7        8       +1     
  Lines         713      779      +66     
==========================================
+ Hits          650      701      +51     
- Misses         44       54      +10     
- Partials       19       24       +5     
Impacted Files Coverage Δ
drivers/hashmap/hashmap.go 87.90% <75.80%> (-12.10%) ⬇️
drivers/hashmap/byte_slice.go 100.00% <100.00%> (ø)

content, err = yaml.Marshal(db.data)
}
if err != nil {
return err
Copy link
Owner

Choose a reason for hiding this comment

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

Should we add a bit more context on this error before returning it?

return err
}

return os.WriteFile(db.config.Filename, content, 0755)
Copy link
Owner

Choose a reason for hiding this comment

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

Same with this, if it returns error a bit more context around it would be useful

Copy link
Owner

Choose a reason for hiding this comment

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

Could we create a table test of valid and invalid file/contents combinations?

Copy link
Owner

Choose a reason for hiding this comment

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

One thing that might be worth considering is base64 encoding values before writing the json/yaml. Since we accept a byte slice the value can be anything even things that break json or yaml formats.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the comments! I will add more context to the errors that you mentioned and also add some additional tests.

The JSON marshal will automatically encode the byte slice into a base64 string. I think the YAML handles it by making a block scalar. I'll add some more table tests with more complex data to confirm these things. Then I can base64 encode the YAML if there are any issues.

Copy link
Owner

Choose a reason for hiding this comment

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

Ah, good point. I had forgotten that the JSON encoder will automatically base64 to encode a byte slice. But I agree, more tests will help ensure that everything stays the same as packages get updated and more changes are made.

@madflojo
Copy link
Owner

I think this is a super cool idea. I like the optional approach where it only happens if the file name is set. Thanks for the pull request it’s super appreciated!

- Add more context to errors
- Test invalid file contents Setup error
- Test writing and reading more complex map data to files
Copy link
Owner

@madflojo madflojo left a comment

Choose a reason for hiding this comment

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

This looks pretty good. Are you ready for merging (as soon as actions are complete?)

@calvinmclean
Copy link
Contributor Author

This looks pretty good. Are you ready for merging (as soon as actions are complete?)

Yes, works for me! I don't think I can get the coverage any higher.

@madflojo
Copy link
Owner

This looks pretty good. Are you ready for merging (as soon as actions are complete?)

Yes, works for me! I don't think I can get the coverage any higher.

Yeah, I don’t see an easy way to match the same coverage once we start interacting with disk.

@madflojo madflojo merged commit 4609e29 into madflojo:main May 25, 2023
@madflojo
Copy link
Owner

Thanks again!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants