Is this feasible somehow?
Foo.bar() #=> "bar"
Bar.foo() #=> "foo"
Context.perform do
Foo.bar() #=> "context_bar"
Bar.foo() #=> "context_foo"
end
1 Like
I’d never recommend doing different things in different contexts without explicitly passing in the context, but there are a number of ways, passing in hidden data in the process dictionary, making perform be a macro that does different things to calls, etc… There are lots and lots of different way, almost all of them are not suggested. 
If you have a more specific complete example that we could fill in a few bits for you, then we can show you, but again, not recommended. ^.^
2 Likes
This looks like a classic X Y problem (http://xyproblem.info/). What are you trying to accomplish in general?
There are a few options that look like that, each is a bit different in what it entails.
Pool.checkout(fn worker ->
# now I can do stuff with the worker
end)
Repo.transaction(fn ->
# stuff here executes in a transaction
end)
object :user do
field :name, :string
# this is a macro based DSL
end
Each of these works differently, and is used for different purposes. We need to know about what you’re trying to accomplish broadly speaking so that we can direct you in the right way.
3 Likes
It is the second case, I am working on a database driver named xarango. I am looking to see if I can use the same API for direct calls (producing HTTP request/responses) and calls inside a transaction (producing javascript code to be run on the server). But based on my insights so far I think I need a dedicated API for transaction calls.
Actually that might be a good case for using the process dictionary. If the transaction call happens in another process (whether the repo process itself or a new one) the transaction call can decorate the process by setting a key in the process dictionary, then your calls can just test for that.
I’m still not a fan of differences in operation based on state like that, but as long as it acts the same inside and outside the transaction, it makes sense.
Thank you for your suggestion. Process.put/2 and Process.get/1 indeed look like they provide the ‘global state’ I could use.
I would have to store a fairly complex and frequently accessed %Transaction{} struct in there though, since I need to concatenate subsequent transaction results and execute them as a whole. Besides all this becoming a bit un-functional, are there any (perhaps performance) objections to this?
Not at all functional (maybe could be considered some implicit ‘this’ maybe?), but it should be fast enough as when structs are changed then anything unchanged is handed over straight, only changed parts and the parts that contain them are recreated.
Do note, the process dictionary is very fast, generally only used as an optimization thing, or for doing non-functional stuff like this. ^.^
I think I will just make a dedicated Transaction API after all. This keeps me on the functional straight and narrow and gives me optimal flexibility for when the nasty details appear.
1 Like
