These are chat archives for bluestreak01/questdb

Jul 2015
Suminda Dharmasena
Jul 04 2015 15:30
Sorry what I meant is get rid of the writer and reader abstractions. All this can be abstracted as journal with a schema. Physically they can be in separate files but logically this is like a normal DB with a Schema which contains many tables and a DB which contains many Schemas. The current journal can be the DB abstraction.
This is purely renaming to match familiar concepts and some fluent APIs abstract away the reader and writer
Vlad Ilyushchenko
Jul 04 2015 21:44
@sirinath I get it now, thanks. Initial version was the way you suggested. There can only be single instance of writer for same journal at any given point in time. This is the case even cross processes. Attempt to create second writer instance will result in exception. At the same time there could be multiple simultaneous readers against the same journal. If both reader and writer function is wrapped by a same interface single writer enforcement will be deferred and less clear as some methods will work some will not. Also having single interface hides intent of passing around instance of Journal class.