Comments (9)
@tlvenn I'm thinking about creating this type of interface internally:
lpop = fn([ head | tail ]) ->
{ head, tail }
end
rpop = fn
(list) when length(list) > 0 ->
{ List.last(list), :lists.droplast(list) }
(list) ->
{ nil, list }
end
Cachex.start_link(:test, [
commands: [
last: { :return, &List.last/1 },
lpop: { :modify, lpop },
rpop: { :modify, rpop }
]
])
{ :ok, true } = Cachex.set(:test, "my_list", [ 1, 2, 3, 4, 5 ])
5 = Cachex.invoke(:test, :last, "my_list")
1 = Cachex.invoke(:test, :lpop, "my_list")
2 = Cachex.invoke(:test, :lpop, "my_list")
5 = Cachex.invoke(:test, :rpop, "my_list")
4 = Cachex.invoke(:test, :rpop, "my_list")
3 = Cachex.invoke(:test, :last, "my_list")
[3] = Cachex.get!(:test, "my_list")
That way you can define custom functions on the cache (from outside). Internally we can just use this to surface some of the more common functions, perhaps those which can be optimized. Any thoughts?
Trying to make this extensible, rather than Cachex having to implement lots of different use cases.
from cachex.
@tlvenn do you mean similar to the commands Redis offers?
The issue here is that we back a cache with an ETS table, which only supports get/set by default. I can add things like list operations but it would have to be known that they're going to be a transactional get/set under the hood. Unless we move away from ETS (which might be viable now distribution is gone), there's no better way to implement that.
Are you interested in the features because of the sugar (i.e. convenience)? Or do you want O(1)
perf against them, etc?
from cachex.
Does not have to match exactly what redis offer but you get the idea. ETS table are indeed problematic and while convenience would already be very nice, i have the feeling people will just assume it can perform on the same complexity level as Redis and it will not be pretty ;)
I guess I am just wondering what the roadmap is and if such thing is outside of the scope of cachex.
from cachex.
@tlvenn so the scope is just whatever is requested, as long as it doesn't damage what's already there ;) A Set op would be pretty fast still, probably 10ยตs per operation (for inserts), so it's not horrible
from cachex.
Good to hear @zackehh , then I honestly think it would be nice to have basic set and list semantics.
from cachex.
@tlvenn just so you're aware, you can use get_and_update/4
in the meantime to have those types of semantics. You'd have to handwrite the modifications made but you could easily do so, and it would still be sufficiently fast.
from cachex.
Ya i was thinking it would be best to keep data manipulation as close as the data source itself from a process perspective.
from cachex.
Hi, I'm thinking about using Cachex to pre-generate a feed of posts (on a per-user basis) for a Twitter-like application.
The thing I'm concerned with is race conditions. If I call get_and_update/4
10 times per second on the same key (to add elements to the list), do you think it would be a problem?
from cachex.
@alexgleason this got lost in my mailbox, so I'm waaaay too late to notice this, but for anyone coming back to this thread: no, calling it multiple times on the same key will run them sequentially and avoid races.
from cachex.
Related Issues (20)
- Does `Cachex.fetch` accept `ttl` option? HOT 4
- Supervisor.start_link/2 HOT 2
- Sending a message to `self()` when starting a warmer crashes app HOT 8
- [question][guidance] bulk increment with ttl HOT 3
- Using Cachex with Phoenix and iex HOT 4
- [Elixir 1.15] ** (MatchError) no match of right hand side value: {1, {:error, :no_cache}} HOT 3
- Cachex.fetch hangs and breaks my app HOT 13
- Cachex warmer breaks the application with "no match of right hand side value: {:error, :no_cache}" error HOT 11
- Possible bug in :cachex_notify event handling? HOT 1
- Using `ordered_set` type tables to back cache HOT 1
- qlc error - max limit cache eviction fails for no cwd write permissions HOT 3
- Consider upgrading provisions to support Warmers as well as Hooks HOT 1
- Warmer blocking should be enabled on cache, rather than individual warmers HOT 2
- Warmers should have names defined, rather than simply the module name
- The :transactional option should be renamed to :transactions
- Cachex.warm/2 should be able to flip between blocking vs. non-blocking
- Remove set and set_many from the public API
- Migrate from using jump hashing to libring
- Create an abstraction over cluster state and routing
- Improve documentation on distributed caches
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cachex.