Ilya, thanks for the ticket. However, I would advise us to enforce "user.home" as the only one default instead of the proposed fallback mechanism. There is already a lot "if else if else if else" scenarios in Ignite. Let's focus on simplicity and stick to one possible option when it works. This case is an example when one option is doable and preferred.
Btw, sounds like 2.7.7? - Denis On Fri, Oct 4, 2019 at 8:34 AM Ilya Kasnacheev <ilya.kasnach...@gmail.com> wrote: > Hello! > > I have created https://issues.apache.org/jira/browse/IGNITE-12260 > > Regards, > -- > Ilya Kasnacheev > > > пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin <vololo...@gmail.com>: > > > Interesting things about those LINQPad/JPad scenarios. Was not aware > > of it. Still some doubts about applicability. It seems to me that JPad > > having work dir in "Program Files" have a lot of problems by itself, > > e.g. a user is not able to run basic file IO snippets with relative > > file paths. > > > > чт, 3 окт. 2019 г. в 23:24, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > > Ilya, fallback is a good idea. > > > Still I'd prefer to have user.home as a default, and fallback to > user.dir > > > when home does not work for some reason. > > > > > > On Thu, Oct 3, 2019 at 11:07 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > We can try and fallback to home dir with warning, when file cannot be > > > > created in current dir. > > > > > > > > WDYT? > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > > > > > > Cannot tell about NuGet. Maven is typically used during > > development, > > > > > usually there is no Maven in production deployments. > > > > > NuGet and Maven are very similar. Yes, both of them are build-time > > tools, > > > > > production is unrelated. > > > > > For production-ready deployments we can expect users to tweak > Ignite > > to > > > > > their needs, set custom storage dirs, adjust heap sizes and so on. > > > > > > > > > > I'm talking about new users, about "getting started" scenarios - > > > > > it is super important to make Ignite easy to get started with, > > provide > > > > > reasonable defaults for all the configuration properties. > > > > > > > > > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > > > > > scenarios. And this scenario got broken as explained above. > > > > > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work > > > > directory > > > > > does not exist and cannot be created: C:\Program > > > > > Files\LINQPad5\ignite\work" > > > > > > > > > > For Java there is JPad, which will fail in the same way - when you > > run > > > > code > > > > > from there, `user.dir` points to Program Files. > > > > > > > > > > I expect that there are more use cases like this, and `user.home` > is > > a > > > > > reasonable solution. > > > > > > > > > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
