>> How about using both escaping and a text file with the name? One can
think of the escaped name as of a kind of ID, which happens to be
human-readable when the name is in ASCII,
and as unreadable as an UUID when the name is in UTF. This way we have all
the readability in the common case (when
is all
English letters and digits),
and some limited readability (via looking into text files) when other alphabets
are used.
Thanks,
Stan
From: Pavel Tupitsyn
Sent: 16 января 2018 г. 14:01
To: dev@ignite.apache.org
Subject: Re: Handling slashes in cache names
> folder named by ID and
> folder named by ID and txt file inside should do the trick
Agree
On Tue, Jan 16, 2018 at 1:02 PM, Dmitriy Setrakyan
wrote:
> On Mon, Jan 15, 2018 at 7:31 AM, Pavel Tupitsyn
> wrote:
>
> > > You will never ever relate smth like "fdee0456adcc" to
On Mon, Jan 15, 2018 at 7:31 AM, Pavel Tupitsyn
wrote:
> > You will never ever relate smth like "fdee0456adcc" to "мои_данные".
>
> As a user, why do I need to understand file names in Ignite work directory?
>
Because it is better to have an understandable and human
On Mon, Jan 15, 2018 at 7:11 AM, Pavel Tupitsyn
wrote:
> > try creating a directory on all nodes
> And then a new node appears with a different kind of file system..
>
If a new node cannot create an existing cache, it should not be allowed to
start.
To understand how much storage you need for cache group "X" and watch the
trends.
Anyway, folder named by ID and txt file inside should do the trick =)
--Yakov
> You will never ever relate smth like "fdee0456adcc" to "мои_данные".
As a user, why do I need to understand file names in Ignite work directory?
On Mon, Jan 15, 2018 at 6:22 PM, Yakov Zhdanov wrote:
> >> And then a new node appears with a different kind of file system..
>> And then a new node appears with a different kind of file system..
This is hardly possible. And I suggest not to
>> Escaping removes all limitations and does not affect usability.
Disagree. You will never ever relate smth like "fdee0456adcc" to
"мои_данные".
Guys, I just realized that we
> try creating a directory on all nodes
And then a new node appears with a different kind of file system..
Escaping removes all limitations and does not affect usability.
Pavel
On Mon, Jan 15, 2018 at 5:47 PM, Yakov Zhdanov wrote:
> Agree that cache names should be case
Agree that cache names should be case insensitive - currently it seems that
we have issues on Windows OS.
As far as allowed characters - why don't we try creating a directory on all
nodes (but calling toLower() prior to creation)? If creation succeeds
everywhere then cache name is acceptable. New
abilistic) failsafe for that.
Thanks,
Stan
From: Dmitriy Setrakyan
Sent: 2 января 2018 г. 16:40
To: dev@ignite.apache.org
Subject: Re: Handling slashes in cache names
On Fri, Dec 29, 2017 at 2:28 AM, Stanislav Lukyanov <stanlukya...@gmail.com>
wrote:
> > I would surround such repla
On Fri, Dec 29, 2017 at 2:28 AM, Stanislav Lukyanov
wrote:
> > I would surround such replacements with "_", e.g.
> "myCacheName_somesymbol_".
> Looks nice, will do.
>
> > Here I am confused. I think the cache names should be case insensitive at
> > all times. I seriously
mpact, it affects a different
part of the code base, etc). Is it OK?
Thanks,
Stan
From: Dmitriy Setrakyan
Sent: 28 декабря 2017 г. 22:33
To: dev@ignite.apache.org
Subject: Re: Handling slashes in cache names
On Thu, Dec 28, 2017 at 9:22 AM, Stanislav Lukyanov <stanlukya...@gmail.com>
ce is not the only place that doesn’t like special
> symbols in cache names – I also got an exception from MBean registration
> when creating a cache with ‘*’ or ‘?’. Filed https://issues.apache.org/
> jira/browse/IGNITE-7334 for that.
>
> Please let me know if you have any comments.
>
>
декабря 2017 г. 18:09
To: dev@ignite.apache.org
Subject: Handling slashes in cache names
Hi all,
I’m looking into https://issues.apache.org/jira/browse/IGNITE-7264, and I need
some guidance on what’s the best way to approach it.
The problem is that cache names are not restricted, but i
On Wed, Dec 27, 2017 at 8:05 AM, Pavel Tupitsyn
wrote:
> Yep, base64 is just an example.
> We need some kind of urlencode, but tailored for file names, so that
> names remain readable.
>
> To avoid uppercase/lowercase collisions on Windows, we can restrict allowed
>
Igniters
Use cache name for file and directory names on a file system is bad idea.
In that case we should keep in mind many limitiations vary FS.
Why do not use mapping cache name to an identifier tolerated to FS lacks?
On Wed, Dec 27, 2017 at 7:05 PM, Pavel Tupitsyn
Yep, base64 is just an example.
We need some kind of urlencode, but tailored for file names, so that
names remain readable.
To avoid uppercase/lowercase collisions on Windows, we can restrict allowed
characters
to lowercase English letters and numbers, - and _, and escape everything
else in some
On Wed, Dec 27, 2017 at 6:25 AM, Vladimir Ozerov
wrote:
> Having different policies for persistent and non-persistent caches sounds
> like a bad idea for me, because there could be troubles should user try to
> switch to persistent mode. It would require code changes.
>
>
Having different policies for persistent and non-persistent caches sounds
like a bad idea for me, because there could be troubles should user try to
switch to persistent mode. It would require code changes.
Can we just escape all non-latin symbols (e.g. using base64), while leaving
the rest as
On Wed, Dec 27, 2017 at 3:42 AM, Pavel Tupitsyn
wrote:
> Agree with Stan and Vladimir.
> We should not impose any restrictions on cache names, some users may have
> issues with that.
>
> Using cache names as file names is internal implementation detail.
> We can use cache
;> it :) ).
>> >
>> > The question is whether or not these considerations worth adding code
>> and/or changing existing behavior.
>> >
>> > BTW Java folks had similar discussion on Java module names resulting in
>> http://mail.openjdk.java.net/piperma
; > BTW Java folks had similar discussion on Java module names resulting in
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-December/000515.html.
> >
> > Thanks,
> > Stan
> >
> > From: Vladimir Ozerov
> > Sent: 27 декабря 2017 г. 14:37
>
ilar discussion on Java module names resulting in
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-December/000515.html.
>
> Thanks,
> Stan
>
> From: Vladimir Ozerov
> Sent: 27 декабря 2017 г. 14:37
> To: dev@ignite.apache.org
> Subject: Re: Handling slashes in
Ozerov
Sent: 27 декабря 2017 г. 14:37
To: dev@ignite.apache.org
Subject: Re: Handling slashes in cache names
Cache name appears to me purely logical entity. Can we simply store cache
ID in file system paths without adding any restrictions to cache names?
On Wed, Dec 27, 2017 at 2:26 PM, Stanislav
eate a Path for “cache-”
>
> Stan
>
> From: Igor Sapego
> Sent: 26 декабря 2017 г. 17:59
> To: dev@ignite.apache.org
> Subject: Re: Handling slashes in cache names
>
> There are also some international features that you might want to
> address. For exam
lity point of view to
> > forbid all these characters now for all caches?
> >
> > Thanks,
> > Stan
> >
> >
> > From: Alexey Kuznetsov
> > Sent: 26 декабря 2017 г. 7:51
> > To: dev@ignite.apache.org
> > Subject: Re: Handling slashes
t;
> From: Dmitriy Setrakyan
> Sent: 26 декабря 2017 г. 17:02
> To: dev@ignite.apache.org
> Subject: Re: Handling slashes in cache names
>
> Looks good to me. Is this going to be an exception on startup? If yes, is
> it safe to release it, or should we wait till 3.0?
>
>
f view to
> > forbid all these characters now for all caches?
> >
> > Thanks,
> > Stan
> >
> >
> > From: Alexey Kuznetsov
> > Sent: 26 декабря 2017 г. 7:51
> > To: dev@ignite.apache.org
> > Subject: Re: Handling slashes in cache names
>
ward compatibility point of view to
> forbid all these characters now for all caches?
>
> Thanks,
> Stan
>
>
> From: Alexey Kuznetsov
> Sent: 26 декабря 2017 г. 7:51
> To: dev@ignite.apache.org
> Subject: Re: Handling slashes in cache names
>
> It also make
mpatibility point of view to
forbid all these characters now for all caches?
Thanks,
Stan
From: Alexey Kuznetsov
Sent: 26 декабря 2017 г. 7:51
To: dev@ignite.apache.org
Subject: Re: Handling slashes in cache names
It also make sense to limit cache name length to reasonable length.
Because some F
It also make sense to limit cache name length to reasonable length.
Because some File systems could have limitations on path length.
See: https://en.wikipedia.org/wiki/Filename#Length_restrictions
On Tue, Dec 26, 2017 at 1:41 AM, Dmitriy Setrakyan
wrote:
> My preference
My preference would be to prohibit forward and backward slashes in cache
names altogether, as they may create a false feeling of some directory
structure, which does not exist. We should also prohibit spaces as well.
D.
On Mon, Dec 25, 2017 at 7:09 AM, Stanislav Lukyanov
Hi all,
I’m looking into https://issues.apache.org/jira/browse/IGNITE-7264, and I need
some guidance on what’s the best way to approach it.
The problem is that cache names are not restricted, but if persistence is
enabled the cache needs to have a corresponding directory on the file system
34 matches
Mail list logo