Using a different medium to store logs apart from `txt`
Closed this issue · 14 comments
I think using json to store entries could open up opportunities for new features,
Instead of storing the entry as a string in a .txt file, we could try breaking up the string to get useful information that we can use to group entries.
Example:
We could be able to group entries by month, week, year etc
Plus, it should be easier to use json data in the program.
We could even try grouping by tags
That should be cool right.
Please assign me to this issue
Great idea, go ahead :)
Personally, I find working with JSON in Python to be a bit sticky, if you could make some basic functions/methods that handle the basic JSON related transactions that would be appreciated
Please be advised of the changes in #31
Currently the tags are stored as #tag-name at the end of the entry line. I think it would be nicer if the tags are stored separately from the text so that they won't show up in regular, non-tag related queries
Sure, I would try to hack a solution real quick,
About JSON being quite sticky, I'm probably on the verge of experiencing that for myself,
Hopefully, I might come up with something that works
I might even consider using SQL
That's why I choose a .txt format like jrnl uses.
Let's avoid using heavier formats like databases.
If JSON doesn't work out, how about creating a .happy directory. Each tag can be stored under a different .txt file. And attributes and info can be stored in each line separated by special characters allow reading the line and then doing a .split
Okay, I will continue trying json, I think I might have already come up with an idea on how to use it here.
I will work on it soon.
Hi, I'm already making progress on this.
At first, looking through the entire codebase and figuring out what to change that wouldn't cause a big mess was a little sticky.
Now I have managed to modify the write_file() to successfully store logs in .json format.
I've also modified part of read_file() to extract necessary data from logs (e.g: date, tag etc), the only things left are the tags and count arguments which I'm still figuring out how to work with.
display_entry now works by directly interpolating extracted data from the log argument, the only bug in this function I need to fix is count and tag (again).
By the time I'm ready to send in the PR I must have fixed all bugs, and the cli should continue to work like it should, except that we'll be using .json and not .txt.
I actually think the switch might help improve performance a little bit, because I'm completely removing the need for RegEx and any string processing.
🔥 🔥
I believe count should count the number of objects in the logs array?
What is the issue with tags?
fire fire
I believe
countshould count the number of objects in the logs array?What is the issue with
tags?
In the display function, the log object was passed directly to output instead the extracted data from the log,
which is only supposed to happen when count or tag is being passed in then function, where log would now represent an integer value representing count or tags.
I will fix that soon, I just need to take a few steps back an analyse the whole thing once more.
Ah sorry, I confused get tag with get tags
Okay, I might have to change a lot of stuff in the algorithm for read_file.
But I promise everything should work as intended
👍
lmk if i can help with anything
How about giving entries unique id's. This could help with editing specific entries as well as the count command if the id is increased incrementally by 1.
I'll think about that too