Igniters, I can't disagree with Nikolay that, as a database, Ignite needs to persist changes to a folder different from "user.home" one. But with the current rate of project growth and adoption, I would encourage us to eliminate any possible obstacles a user might come across during the getting started phase with Ignite. Unfortunately, folders different from "user.home" imply a significant restriction - the user needs to allow access to folders like /lib, /etc; which can make every getting started demo or app fail.
Thus, today, I'm casting my vote for "user.home"/ignite/work directory. Please don't forget about Windows and MacOS. - Denis On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn <ptupit...@apache.org> wrote: > +1 for ~/.ignite/work > > As Petr mentioned above, this translates well to Windows and MacOS too, we > can use "home directory" term in documentation and it works for any OS. > > On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov <nizhi...@apache.org> > wrote: > > > AFAIK server admin expects software will store it's data in /var/ > > directory, not in /home directory. > > > > > In Docker age, packages are becoming extinct. > > > > I don't agree with that, but seems, it's not a subject of discussion. :) > > > > > we don't even have very good packages today > > > > Why do you think we don't have good packages? > > What is wrong with the current one? > > > > > I also think we should not copy what other DBMS do since their > > ease-of-use > > > is usually lacking > > > > We should define 'easy-of-use' here. > > My experience with the modern dbms(postgres and mysql) is different. > > > > > > В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет: > > > Hello! > > > > > > I think it is 2., because if a node is run from Ignite binary > > distribution > > > it has its root as a ignite work directory. I think it it another > > argument > > > for keeping data under current dir - Ignite binary distribution already > > > does it, why should embedded scenario be different? > > > > > > In Docker age, packages are becoming extinct. Nobody wants them > anymore, > > > anyway. I don't see why we should aim for those since we don't even > have > > > very good packages today, and nobody wants to contribute towards their > > > improvement. > > > > > > I also think we should not copy what other DBMS do since their > > ease-of-use > > > is usually lacking (this is from someone who had to support mysql and > > pgsql > > > deployments). > > > > > > Regards, > > >
