Flaksator – testing noSQL DB and dictionaries storage

In the previous post I’d described interface for storing String Lists as collections. In the meantime, I’d decided that StringWrapper was not good name for that object, and therefore I’d decided to change it into StringCollectionWrapper.

In this post I’m then continuing with noSQL storage.

Testing StringCollection storage

I’d decided to keep shared data file as part of the solution (/Data/Flaksator.db) to be able to easily manage it using GithubPlugin. Because there are / will be several projects that depend on it and are located on different level in file system hierarchy I do expect to have problems with accessing it – or having to manage different, scattered configurations. While clean unit tests should do not depend on any external resources, current piece of tests (kind of integration tests, I guess) require access to physical DB. The problem is that I prefer to keep test projects in dedicated subfolder in both file system and solution. Therefore path to db file is different depending from where it is going to be called:
Czytaj dalej Flaksator – testing noSQL DB and dictionaries storage

Flaksator – storing core resources in noSQL

As I’d already mentioned, I’m going to store all Flaksator’s resources in noSQL database. I’d already decided to use lightweight (it’s just package / DLL) implementation.

And before I start I owe one explanation to English speaking visitors. Flaksator is just a play-on-words: original library responsible for managing Polish flection rules I’d called „Fleksator”, from Polish „fleksja” meaning „flection”. Then, my – more or less – funny application that randomized brutal, blasphemous lyrics I’d called „Flaksator”, which differs only by one, yet meaningful letter from library name. The Polish word „flak” means „guts, entrails, bowels” in English. Pleas enjoy my creativity 😉

I know I have several types of resources in the Flaksator:

  1. Simple lists of strings (title verses templates, verse templates, song static elements)
  2. Simple dictionary items (translations, enumerations, word categories)
  3. Definitions – complicated dictionaries (mainly postfixes lists)
  4. Word definitions themself (will be covered in next article).

Czytaj dalej Flaksator – storing core resources in noSQL