Hi all,
Sorry to join the party so late.
This is a topic that has been discussed multiple times already, just to give you some links:
So here the discussion is a bit reduced in scope, what you are more or less asking for is a human readable/modifiable version of the content of MapDB, right? So yes, an export/import mechanism might be the easiest solution for that.
Some remarks:
- It isn’t trivial to implement a database, so I would not try to replace MapDB by something done on your own. Rather do export/import only.
- Alternatively, any other database/storage mechanism can be hooked in, since ESH nicely abstracts this layer
- The database storage must be in all cases independent of DSLs/Xtexts. Note that it was introduced to give systems a chance to operate completely without any Xtext stuff as Xtext is quite heavyweight for small embedded systems. What is worse is that it brings a lot of complexity to the runtime. I spend 3 full days last week getting the circular dependency issue fixed, which was to a big part due to Xtext using Guice. As I seem to be the only person on the planet being able to analyze and fix such issues, you do not want to bet on this for own safety!
- As the internal format of Things in MapDB is indeed JSON, JSON would be the most natural fit for an export/import format.
- I agree that it would be nice though to be able to export directly in the DSL format as well, which is handy for all users who want to further maintain it as a text file themselves. If you want to implement this, it has to be optional (see above) and you should avoid duplicating code. The Thing DSL e.g. still sometimes evolve and changing the format should not require code changes at very different places. So serialization to DSL format must be done through Xtext itself, which supports this.
Just my 2 cents 
Kai