Hello! I want to point out that I didn't change this location (current dir). It was already implemented when I raised this issue, the only change I did was to swap current dir/work to current dir/ignite/work to avoid confusion whose work dir that is.
I also communicated this to you all in ML when I discovered that current dir is used. I think that current dir is actually *well defined* when starting a project. A project is expected to be started from the same dir, and all "Run..." dialogs usually allow specifying that one. For embedded scenarios, you definitely not want work dir from two different Ignite-using tools to interfere. For embedded scenarios, you should only expect that current dir is writable. Even after these considerations, it's too late to change that because people don't expect this dir to move with every release of Ignite, and we already did it once. Regards, -- Ilya Kasnacheev чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > > Seems, we should have different defaults and even distributions for > > different usage scenarios. > > > I still do not understand why defaults should be different for embedded and > "traditional RDBMS-like" installations. Having different defaults will > likely confuse users, not make usability easier. Personally, I would forbid > to start Ignite if IGNITE_HOME is not set, but this suggestion was not > accepted by the community. > > As far as I know, both rocksdb and SQLite is local only libraries and don't > > have any distrubted features. > > See no difference here. Imagine a user starts only one Ignite node for > development or just to play (which, I believe, happes quite a lot) - same > as with local databases. BTW, it is impossible to start SQLite without > database path, so a user either provides a full path, or a relative path > from the current directory - which is an explicit action from a user. > > > > I agree with you. > > How it happens, that after wide discussion we implemented, reviewed and > > merged wrong defaults? > > > > As I know, we have explicit release only to change this default. > > > > This release is broken, isn't it? > > > I think this is just a miscommunication. Ilya made a fix which was exactly > what he meant it to be. As for the release - it may have worse usability, > but not more 'broken' as the previous one with the temp directory. At least > the data will not be physically removed after the machine restart. >
