Closed sgjava closed 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.
Ah, I need to argue with Romain :)
@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?
You could call it a query, subset, etc., but the functionality would be well received. This isn't a corner case.
@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:
@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 :(.
Okay, so the answer is:
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.
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.
@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.
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.
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.
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.
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.
Thanks @brianoliver. Is there a Feature page for 2.0+?
There is a Label called "JCache Next", which is what this issue is already tagged with ;)
I have something like:
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