If the key ends with the configurable character (which is a colon by default) then it is treated as a partial removal. It should be in the remove methods of the memory cache and the disk cache.
I think non String keys will be ignored. If you want to use string keys then you can use this hierarchical / partial removal. It is extremely useful. I think I mentioned it in some of the documentation. > -----Original Message----- > From: John McNally [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 29, 2002 3:14 AM > To: Turbine Developers List > Subject: Re: a few things -- RE: cvs commit: jakarta-turbine- > stratum/src/java/org/apache/stratum/jcs/engine/control/group > GroupAttrName.java > > Aaron Smuts wrote: > ... > > A few comments: > > > > > Log: > > > fixed several places that were assuming keys were Strings, they can > be > > > any Serializable object. > > > > This may not (or should not?) be the case. There is a hierarchy > > functionality that may assume that the keys are strings. The keys are > > checked to see if they end with the wild card ":". We could add a > special > > remove method that forced string keys? > > > > I started forcing the string values for a reason. I can't remember the > > status of this. > > > > I started using a special purpose object as the key when using jcs > within torque. I did not get any casting exceptions, though I am only > using the memory cache, so I have not tested the full functionality. > Can you point to where the hierarchy is implemented? What happens if > the key contains colons that are not meant as separators? > > > I see little value in non string keys. We can get much more > functionality > > with string keys. The partial removal is extremely powerful. It allows > you > > to avoid the overhead of groups and clean up quickly. It cannot be > > sacrificed. > > You use the value of general keys in creating GroupAttrName and > GroupId. And I am using it in torque. I would like to see the wildcard > implementation. But looping over all the keys parsing each one to look > for a partial string does not sound efficient. > > > > > Any thought on the value of non String keys? > > > I have a List that I would like to cache. The objects that are in the > list depend on a set of other objects. So I make the set of objects the > key. Not sure how I can use a String to accomplish this easily and I > cannot force the positions of colons. I guess I could make sure to > remove any colons from any strings that are generated. What is the > overhead of groups that makes all this work attractive? > > > > > > > > > fixed one place that assumed the group name was an Object. It is > > > currently > > > always a String. > > > > > > made CacheException extend commons NestedException. This gave a > > > classpath > > > issue in RMI, that I do not fully understand, but giving the > commons- > > > lang jar > > > as a classpath attribute allows the build to work. > > > > > > fixed a few places where jcs was ignoring exceptions with no > explanation > > > as to > > > why. There are quite a few more. > > > > > > > Early on, following JCache, I started throwing exceptions for common > > scenarios like the object was not found or already existed. This made > it > > cumbersome to use and followed a model of excessive exception throwing > that > > I find distasteful, so I removed them. In the process I commented out a > few > > IOExceptions that maybe I shouldn't have. I'm not sure that an > exception > > will ever get pushed up that high though. > > > > I'd like for the user to only have to import the root package. They > should > > be able to use the JCS access class. Maybe a root or abstract > JCSException > > class should be put in the same folder to make it easier to use. There > is > > nothing worse then having to figure out a million imports to use third > party > > software. > > > > I was assuming CacheException would be the main/general exception thrown > by jcs. I'm all for moving it to the top level. For that matter I > think the interfaces should be top level with implementations pushed > further down. > > john mcnally > > -- > To unsubscribe, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]>
