-
Notifications
You must be signed in to change notification settings - Fork 337
Conversation
I'm not super happy but It kinda works, you need to specifiy the namespace_id in your wrangler.toml. # ...
[[kv-namespaces]]
local_binding = "local_binding"
name = "name"
namespace_id = "abc" |
Re: the There may be situations where they'll need to go look up the namespace manually, but I imagine the average workflow will take place (hopefully!) in Wrangler, so we should know the (BTW - I am super motivated to help make this work land; it's a HUGE pain right now to have to keep the editor UI open right now to re-bind a KV namespace after each publish) |
What is currently holding this PR back from landing? |
@steveklabnik it would require a couple of rebases but I'm happy to see this landing. If you need it I can continue to work on it. |
It'd be nice to get it landed so that we can continue the work on KV support overall; if you've got the time that would be great. |
I think what I'm missing to be able to judge this PR is the README section on how to configure your namespaces in the wrangler.toml; @xtuc touched on it in his comment but what would my wrangler.toml look like if I had two or more namespaces exposed to my worker? |
@ashleymichal it currently looks like this: kv-namespaces = ["STATIC_CONTENT"] if you had two kv-namespaces = ["STATIC_CONTENT", "FOOBAR"]
|
@steveklabnik based on the earlier comment from @xtuc here, that does not appear to be the case in the context of this PR; the user is required to specify not only the name of the binding as it should appear in the Worker, but the "title" and id of the namespace, in order to both create the namespace (if it does not already exist), and specify the binding in the metadata. The question still stands, as once we provide any interface to users, it becomes difficult to change. In order to land this, we need to care about a few things:
I think 1. is well handled here and lays a decent enough foundation for later improvements and features. In the case of 2 and 3, I think it would be short-sighted to go with the seemingly "simpler" approach of requiring the user to only provide the namespace title. It is much easier in the long term to make those three connections explicitly and provide "sane defaults" later than to do the reverse. We should therefore take the time to consider what the entries should look like in the wrangler.toml now. |
config wise- re multiple kv name spaces i'd probably do something like this... keying on "title".. i could also see us keying on local binding. i personally find the existence of both to be redundant (open to hear the motivation and have my mind changed, of course). # Cargo.toml
[kv-namespaces]
title1 = { local_binding: "thing", id : "aksdhjfkahg;a"}
# or, its equivalent
[kv-namespaces.title1]
local_binding = "thing"
id = "aksdhjfkahg;a" collapsing the "local_binding" and "title" (assuming they obey the property with the most constraints constraints...) we could do this instead: [kv-namespaces]
title1 = "aksdhjfkahg;a"
title2 = "<id string>" this is preferrable IMO because it now looks like a list of dependencies! which is nice. |
it should also be noted this is only for the webpack project type, and we have 3 types... choosing to release it for a single type should be a deliberate decision. |
Ah, see when I implemented it, it used the title of the namespace and made a binding of the same name; we decided not to support the case where the two differ.
… On Jun 21, 2019, at 2:04 PM, ashley williams ***@***.***> wrote:
it should also be noted this is only for the webpack project type which is a deliberate decision we should make
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Maybe we could iterate on this PR, to get something useful I would:
This will unlock our deployement and provide a base used for future iterations. We shouldn't document it for now tho. What do you think? |
I agree that the KV config should be in |
55042eb
to
0c3fef2
Compare
0c3fef2
to
34a6b22
Compare
I made an update, mainly based on #215 (comment). @cwndrws comments:
The kv-namespace configuration is only possible in The config looks like the following: [[kv-namespaces]]
name = "KV_NAMESPACE_A"
id = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" I'm not sure we should ask the user for the namespace name because we won't use it, the API doesn't support it. It would be more confusing if these names get out-of-sync and it would still work, until we add a check which would be a breaking change.
I like that idea actually, I updated #90 and we can discuss there. Merge #285 first. |
I agree with not using the namespace name. Your example config: [[kv-namespaces]]
name = "KV_NAMESPACE_A"
id = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" doesn't contain a binding symbol. Should it be: [[kv-namespaces]]
name = "KV_NAMESPACE_A"
binding = "KV_NAMESPACE_A"
id = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" Or something similar? |
@cwndrws the name is the binding, I'm happy to rename it if it's confusing to you. |
This comment has been minimized.
This comment has been minimized.
upon further reflection, i actually do think that long term this is the right way to specify these namespaces. the wrangler.toml for a workers project should regard kv namespaces as an external dependency, and the configuration of that dependency is a separate issue.
i too am struggling with the correct key for |
75a189b
to
dc90d8f
Compare
Allow the user to declare kv-namespaces in the configuration and writes the binding to the worker metadata. Adds a new binding type `kv_namespace`. Extends the Wrangler configuration to add: - `kv-namespaces`: Bind kv namespaces to your worker; an array of: - `binding`: name that will be used to bind the kv-namespace to your script, in JavaScript. - `id`: Identifer of the namespace. For example: ```toml [[kv-namespaces]] binding = "KV_NAMESPACE_A" id = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" [[kv-namespaces]] binding = "KV_NAMESPACE_B" id = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ``` The documentation (README.md) has been updated with this configuration change. Fixes #92
dc90d8f
to
d7fbd78
Compare
I noticed that when the namespace id is wrong, the publishing API returns a unclear error (generic 400, workers.api.error.internal_server); it would be great to change it. @ashleymichal I did the updated. |
Merging into feat-better-kv |
Fixes #92