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 Thu, 03 Oct 2019 19:40:55 GMT
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.
> > >
> >
>

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