Let me return back to this issue. > Well, having to support multiple cache name formats going forward will be > difficult. I don’t think there is a question of multiple name formats. Let’s just say that there are issues that can be solved on the base cache level (e.g. making cache names always case-insensitive) and there are issues that have to be solved by the PDS (e.g. special and non-ASCII symbols that we don’t want to always ban from names). I’m not suggesting to introduce anything to PDS that will afterwards be handled by the base cache code. We’ll just handle some issues first, in PDS, and other issues will be handled separately.
> My preference would be to limit to 255 characters right now That would be good, but it doesn’t really solve the issue with the length. Since non-ASCII characters (and non-alphanumeric ASCII) are encoded, the actual length of a cache’s directory name may be greater than the name of the cache (and don’t forget the “cache-“ prefix). We could come up with a “really safe” limit, but it might be too small (around 80?), and that would be limiting the API based on a rather arbitrary Implementation detail. Another reason why I like to have a hash in the file name is that we might run into problems with two names, one of which is an escaped version of the other, like “my/cache” and “my_2f_cache”. And I guess there can be more similar collisions that we just don’t think of right now. Having a hash in the name just works as a (probabilistic) 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 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 doubt enforcing this rule would cause problems. If > > we enforce this rule at cache creation time, then we would not have to > add > > a hashcode at the end. > I think I would still keep the hashcode. E.g. I’m now also truncating > names longer than 255 chars, and the truncated names could be equal. There > could be more edge cases, and adding an imprint of the identity might help > to avoid them. The names are readable enough with the hashes, but scary > enough for users not to mess with them manually – I guess that’s a good > thing :) Making cache names always case-insensitive sounds good, but I’d separate it > to another JIRA issue (it has larger compatibility impact, it affects a > different part of the code base, etc). Is it OK? > Well, having to support multiple cache name formats going forward will be difficult. I would rather we finalize on it right now. My preference would be to limit to 255 characters right now and make cache names case insensitive. I doubt such change would affect many users, but it would definitely make things cleaner. Would be nice to here what others in the community think. Vladimir O., Alexey G.? D.
