Default JsonSerializerAdapter to record 1 line per journal entry instead of 1 batch per line.

[goblinfactory]

json-example.journal.txt

failing test

(Update : these tests are now out of date.)

Given a memstate db configured to write journal extries as json, 1 line of json per journal entry
When I run a few commands
then the journal file should exist
And the journal file should have saved the entries as text, 1 line per entry

The following code below produces the attached file (see atop) If you open the text file and see multiple lines, turn off word wrap :D

        [Test]
        public async Task Simple_end_to_end_with_human_readable_json_journal_file()
        {
            Print("Given a memstate db configured to write journal extries as json, 1 line of json per journal entry");
            var settings = new MemstateSettings { StreamName = "json-example" };
            settings.Serializers.Register("a-unique-key", _ => new JsonSerializerAdapter(settings));
            settings.Serializer = "a-unique-key";
            var model1 = await new EngineBuilder(settings).BuildAsync<LedgerDB>();

            Print("When I run a few commands");
            await model1.ExecuteAsync(new InitAccount(accountNumber: 1, openingBalance: 100.11M, currency: '£'));
            await model1.ExecuteAsync(new InitAccount(accountNumber: 2, openingBalance: 200.22M, currency: '£'));
            await model1.ExecuteAsync(new Transfer(fromAccount: 1, toAccount: 2, amount: 0.01M, currency:'£'));
            var accounts = await model1.ExecuteAsync(new GetAccounts());
            await model1.DisposeAsync();
            accounts.ForEach(Console.WriteLine);

            Print("then the journal file should exist");
            Assert.True(File.Exists("json-example.journal"));

            Print("And the journal file should have saved the entries as text, 1 line per entry");
            var lines = File.ReadAllLines("json-example.journal");
            Assert.AreEqual(3, lines.Length);
            StringAssert.Contains("M100.11", lines[0]);
            StringAssert.Contains("M200.22", lines[1]);
            StringAssert.Contains("M0.01", lines[2]);

            // to view the journal file in an editor comment out the File.Delete in the test Setup/teardown.
            // The journal file will be located in 
            // Memstate.Docs.GettingStarted\bin\Debug\netcoreapp2.0\json-example.journal
        }

[goblinfactory]

I assume what we're supposed to see is something like this?

json-example-1line-per-journal-entry.journal.txt

Files have been renamed from xx.journal to xx.journal.txt so that they can be uploaded. Journal extensions are not supported by github.

[rofr]

Note also that the actual journal contains 3 arrays (JournalEntry[]), with a single JournalEntry in each. This is due to the group commit behavior: commands arriving at a high rate are accumulated and written in batches to the underlying storage. In the test code above, each command is awaited before the next is written resulting in a single entry per batch.

[goblinfactory]

this comes back to my earlier comments about capturing more information with the "features". I.e. without knowing what is the intention behind having a text file we can't tell if the behaviour is correct or not.

I was working on the assumption that json format files are useful because they are human readable and can act as a logfile that can be used for debugging.

If the behaviour you want is to write batches to single lines that humans cannot read, then shouldn't you make that "intention" clear in the tests/requirements/feature notes? Also it would be helpful to understand what the expected use case is for json text files with single line batches.

in other words I can't even tell whether this issue should now be closed because of what you've stated above? I created this issue because when I spoke to you a few days ago you said that the json format should write 1 entry per line.

[rofr]

One entry per line is a nice-to-have feature. Even without line breaks the journal is accessible for both humans and tools that understand json. The value of json compared to binary format is primarily interoperability and flexibility. JSON can be parsed, interpreted, manipulated, transformed, read, pretty printed using any platform/language that can handle JSON. If we can have one entry per line as well, and I don't see why not, then let's do it!

[goblinfactory]

Txs, will take a look at this in the morning, A

[goblinfactory]

I'm going to label this as a feature request, and tweak the title so that it doesn't look like a bug, which it isn't.

[goblinfactory]

I'm going to close this. I think it's a nice to have but currently a low priority and the tests and notes are no longer in line with the current code. @rofr you can re-open if you want to keep this here but thought you'd appreciate cleaning out any false negative issues.