Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

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 <[hidden email]>:

> >  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 <[hidden email]>
> 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 <[hidden email]
> >:
> >
> > > >
> > > > 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.
> > >
> >
>

[Pavel Tupitsyn]

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 <[hidden email]>
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 <[hidden email]>:
>
> > >  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 <
> [hidden email]>
> > 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 <
> [hidden email]
> > >:
> > >
> > > > >
> > > > > 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.
> > > >
> > >
> >
>

[Ivan Pavlukhin]

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 <[hidden email]>:

>
> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > >  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 <
> > [hidden email]>
> > > 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 <
> > [hidden email]
> > > >:
> > > >
> > > > > >
> > > > > > 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

[Ilya Kasnacheev]

Hello!

I have created https://issues.apache.org/jira/browse/IGNITE-12260

Regards,
--
Ilya Kasnacheev


пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin <[hidden email]>:

> 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 <[hidden email]>:
> >
> > 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 <
> [hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > >  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 <
> > > [hidden email]>
> > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > >
> > > > > > > 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
>

[dmagda]

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 <[hidden email]>
wrote:

> Hello!
>
> I have created https://issues.apache.org/jira/browse/IGNITE-12260
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > 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 <
> > [hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > >  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 <
> > > > [hidden email]>
> > > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > > >
> > > > > > > >
> > > > > > > > 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
> >
>