Jrnl: Store Journals in folder (with multiple files)

Created on 24 Jun 2014 · 16Comments · Source: jrnl-org/jrnl

Hi,

I think it would be great if the program would use several files instead of just one file. One file per day would be feasable, I think!

enhancement

Source

matthiasbeyer

👍2

Most helpful comment

Please note that I'm still interested in this.

Maybe another note why I want this: My current journal has 179 entries, which result in ~4,7 K lines. The files are ~800 kbyte overall, but nevertheless having multiple files seems much nicer IMHO.

Also, I'm writing imag and I'm thinking about integrating jrnl as my diary module. But for this I must be able to identify one entry, and a date is not enough for me. A UUID would be best, a filepath is feasible IMHO.

If you have questions, don't hesitate to ask! :smile:

matthiasbeyer on 12 May 2016

👍3

All 16 comments

Maybe as additional comment: I really like the idea of jrnl, but my current 'diary' setup writes stuff to several files (one file per day), which is much better if you write a _lot_. I would use jrnl heavily, and not only write one line or so to it, but maybe 50 lines per day. Keeping this in _one_ file makes it really long (1500 lines a month, 18k lines per year).

As proposal: My current setup writes a directory-structure as follows:

/
/pages/
/pages/2014/
/pages/2014/01/
/pages/2014/01/01.txt
/pages/2014/01/02.txt
/pages/2014/01/04.txt

I would like if jrnl would do something similar.

The /pages directory is nice because if jrnl grows you can store the
configuration or something withing the 'root' directory.

matthiasbeyer on 24 Jun 2014

Hm, I see the value in this. In the current setup, it would actually be fairly easy to implement that, however hard to implement it well. Ie, jrnl would still open all the files all the time; I'll have to think about the code organisation a bit more to implement this proposal. But I'll keep it in the backlog for 2.0, which should hopefully have a release candidate within a month.

maebert on 25 Jun 2014

Nice!

For the first step I would be fine with opening all files on each run. But maybe others are not fine with it.

The changes from "we read all files on each run" to "we read the required files on each run" would not change the "API" (the file system operations and the cli), so this would be a improvement for later. The changes in the first place change the file system behaviour of the program, so this has to result in a major-version bump. The rest is just runtime-fixing.

I would implement it myself, but I'm not that familiar with python, and I don't want to mess up... thank you for taking this serious!

matthiasbeyer on 25 Jun 2014

I second this enhancement, but also agree it would be more than trivial to implement well.
It was however like the second question I asked myself about jrnl. "Does it give you the option to store entires in multiple files as well as one?" (To give you a new users perspective.) Perhaps a caching mechanism of some sort might be appropriate for a 2.0.0 release, so it have to parse all the files every single time to look for tags and such.

grplyler on 29 Jun 2014

Will this be implemented? It's open for over half an year now... and it seems nothing has happened...

matthiasbeyer on 25 Jan 2015

Hey, I've got something working on my fork of jrnl, in the "folder" branch. There are some bugs with deleting/editing entries, still, so not really ready for prime time, but if you'd like to try it out...feel free.

notbalanced on 26 Jan 2015

This issue is important to me, too. I just found jrnl and it looks like everything I wanted, except the directory/file structure. Is this still being considered by @maebert ? Is there anything I can do to help?

flight16 on 27 Mar 2015

@flight16 :+1:

matthiasbeyer on 27 Mar 2015

@notbalanced I had a look at your change, and it appears you added the changes to the base Journal class. Just curious, what issues did you run into when editing and deleting entries? Were these implementation bugs or design issues?

I am not the author of jrnl, but I think we could cleanly solve this issue by enhancing cli.py and the config to support arbitrary journal formats. There is already DayOneJournal that is hard-coded. All that needs to be done is to create a mechanism to optionally tag a journal as a specific format, and then instantiate the associated class. So I see this issue as "Support custom journal formats".

@maebert Would you accept a pull request for the above enhancement?

flight16 on 31 Mar 2015

@flight16 Hi, my implementation is actually a new Folder class derived from the Journal class (similarly to what is done with the DayOne class.) In the cli.py, I do instantiate the Folder class if the journal in the .jrnl_config is a folder that doesn't have ".dayone" in the folder name.

It works just fine for adding entries to the journal. But when you use the --edit flag, and then delete an entry, it doesn't get deleted. (You'd have to go into the txt file and delete it manually.) I run into this problem because I can have multiple entries in one file (unlike the dayone journal that only has 1 entry per file). I haven't had time to figure out a way to identify which entry gets deleted, so that it doesn't get written when you update the file.

There is also the issue that if you only have 1 entry in a file and delete that entry, that the code doesn't delete the file.

Finally, I haven't had the time to run the tests on the update. I'm pretty sure I've broken something there, so I need to update those tests and add additional tests to cover this new journal type.

notbalanced on 1 Apr 2015

Please note that I'm still interested in this.

Maybe another note why I want this: My current journal has 179 entries, which result in ~4,7 K lines. The files are ~800 kbyte overall, but nevertheless having multiple files seems much nicer IMHO.

If you have questions, don't hesitate to ask! :smile:

matthiasbeyer on 12 May 2016

👍3

@notbalanced @flight16 @matthiasbeyer Thanks for your interest in the project! I just wanted you to know that this is one of my favorite features, and I plan to prioritize it.

We're just getting the project back up running right now, though, and need some time to get everything organized. Thanks for waiting, and look out for this feature!

wren on 21 Jul 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.