Wildcard key match? - Githubissues

sgjava commented 8 years ago

I have something like:

@CacheRemove(cacheName = "recordedEvents")
public void removeRecordedEventsEntry(@CacheKey final String cacheKey) {
    log.debug(String.
            format("%s removed from recordedEvents cache", cacheKey));
}

However, I lose the key suffix (in this case the key is MAC address : start index : count). I'd like to be able to delete all keys matching just the MAC address portion of the key.

See http://tomee-openejb.979440.n4.nabble.com/JCache-partial-key-match-td4677846.html

cruftex commented 8 years ago

That would be a Query. There is no such feature in JSR107.

Please direct usage questions to stackoverflow. Lots of people are monitoring that. This issue tracker is not appropriate.

cruftex commented 8 years ago

Ah, I need to argue with Romain :)

rmannibucau commented 8 years ago

@cruftex this is a feature request so it sounds the place to put it since it is the official JSR bugtracking on JCP page, no?

sgjava commented 8 years ago

You could call it a query, subset, etc., but the functionality would be well received. This isn't a corner case.

cruftex commented 8 years ago

@rmannibucau: JSR107 is done and in maintenance mode. We cannot add new features and can only do very minor corrections.

We do not have a real issue tracker for a (maybe) next 2.0 version of the spec.

Stackoverflow is the better place, because:

More people are tracking this, you will also get ideas from other peoples in the same situation
There will be competent answers (maybe) from Vendors, that have something like this implemented; so there is some prototype how to do it and some experience whether this makes sense
I collect use cases and scenarios for caches on Stackoverflow for three years now
And, you will also find questions about the same thing ;)

rmannibucau commented 8 years ago

@cruftex the question was about a portable feature so it is 100% about having a new release (1.1 or 2.0) so stackoverflow wouldn't help :(.

cruftex commented 8 years ago

Okay, so the answer is:

It won't be in 1.1
Queries was on a "wishlist" for 2.0 on the JavaOne BOF, but there is no work on 2.0 yet

brianoliver commented 8 years ago

As a heads up, we have well define labels and milestones for all issues on github, including for the spec, ri and tck.

Which means you can easily mark an issue for the 2.0 Milestone and label what area the issue relates to.

Easy ;)

— B/

On Mar 11, 2016, at 11:26 AM, Jens Wilke notifications@github.com wrote:

@rmannibucau https://github.com/rmannibucau: JSR107 is done. and in maintenance mode. We cannot add new features and can only do very minor corrections.

We do not have a real issue tracker for a maybe next 2.0 version of the spec.

Stackoverflow is the better place, because:

More people are tracking this, you will also get ideas from other peoples in the same situation There will be competent answers (maybe) from Vendors, that have something like this implemented; so there is some prototype how to do it and some experience whether this makes sense I collect use cases and scenarios for caches on Stackoverflow for three years now ;) — Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/338#issuecomment-195438853.

brianoliver commented 8 years ago

Adding "queries" to the JCache specification is something we've thought about for some time. The challenge is what interface / language to use.

Create yet-another-query-matching language is not an option. Ideally we should be able to use something that already exists, is proven, supported and developers know how to use it. eg: JPA?

Alternatively, perhaps using something like a Lambda Predicate, which we could use in a JCache 2.0, especially if it (and should) target Java 8.

rmannibucau commented 8 years ago

@brianoliver makes sense. Think predicate idea doesn't worth it (we can already iterate over entries) but something deeper in the impl like prefixes organisation was the idea of this issue.

sgjava commented 8 years ago

I'm not sure I'd go for a QL when a Trie https://en.wikipedia.org/wiki/Trie would work. Any ways, I'm not an expert in this realm, so I'm open to all ideas.

gregrluck commented 8 years ago

Not something we can do in the errata release for 1.1. Once JCache 2.0 gets up and running under a new JSR, these suggestions can be made there.

RaviH commented 8 years ago

Any update on this? Is this something that can be worked on or it is "won't do" ideas? I would love to have it.

brianoliver commented 8 years ago

As Greg mentioned in March:

"Not something we can do in the errata release for 1.1. Once JCache 2.0 gets up and running under a new JSR, these suggestions can be made there.”

— Brian

On Sep 22, 2016, at 1:55 PM, Ravi Hasija notifications@github.com wrote:

Any update on this? Is this something that can be worked on or it is "won't do" ideas? I would love to have it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsr107/jsr107spec/issues/338#issuecomment-248978589, or mute the thread https://github.com/notifications/unsubscribe-auth/ACgaxR4ilq2IAPf3Nau79NuVJxoixLrRks5qssEbgaJpZM4HuwNO.

RaviH commented 8 years ago

Thanks @brianoliver. Is there a Feature page for 2.0+?

brianoliver commented 8 years ago

There is a Label called "JCache Next", which is what this issue is already tagged with ;)

jsr107 / jsr107spec

Wildcard key match? #338