ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Replacing default work dir from tmp to current dir
Date Fri, 04 Oct 2019 15:34:24 GMT
Hello!

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

Regards,
-- 
Ilya Kasnacheev


пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin <vololo100@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 <ptupitsyn@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.kasnacheev@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 <ptupitsyn@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.kasnacheev@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.goncharuk@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message