-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: expose flag to determine whether a composite is indexed #196
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically looks good, adding Paul for naming convention questions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me but it misses docs and tests.
75c74b1
to
5194792
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my main question is around the behavior of the --no-index
to the composite deploy command. My understanding is that the very definition of "deploying" a composite means telling the node to index the constituent models.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As pointed out by Spencer, I don't get what is the purpose for deploying without indexing?
That would mean documents can be created but not queried on the node, which seems unlikely to be the wanted user experience?
The desired user behavior is to update their composite with additional indices for querying. That requires create without indexing. However, they may also run deploy, since this is the steps specified in docs, so if they do that, need to do so without indexing. |
char: 'd', | ||
description: | ||
'Deploy the composite to the ceramic node, which will start indexing on the composite', | ||
default: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel super strongly about it, but I lean towards making create not deploy by default, so users have to explicitly deploy when they're ready. I think this will help with more complex situations where devs wants to create and merge multiple composites, possibly adding indices and views along the way, before finally deploying the final unified composite as the last step.
I could be swayed on this though if there's a case for why it's better to deploy by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, what does composite:from-model
do? That one seems even more like it definitely shouldn't auto-deploy since you're likely to want to add indices to it before deploying. And if that one doesn't auto-deploy, then I feel like this shouldn't either just for consistency sake if nothing else
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was doing this just to maintain the existing behavior, so this change won't suddenly cause things to "stop working" for users that aren't calling deploy.
I'm not entirely sure which way is better either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, I guess preserving existing behavior makes sense
@@ -117,6 +123,12 @@ available on the Ceramic Node that yor DApp connects to. You can find a detailed | |||
guide on Composites' deployment | |||
[here](https://developers.ceramic.network/docs/composedb/guides/data-modeling/composites#deploying-composites) | |||
|
|||
If updating your composite to add additional query fields, do not run this command. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, I think we need to be clearer with our language here about what exactly the problematic scenarios are and what the proper recourse is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did the language here get updated? I like the language you used for the create
command above (mod one small suggestion), can we re-use that?
Adds a flag to deploy composite when creating, which is defaulted to false. Additionally adds a flag to disable or enable indexing when deploying a composite.
71292dd
to
2e41e5e
Compare
char: 'd', | ||
description: | ||
'Deploy the composite to the ceramic node, which will start indexing on the composite', | ||
default: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, I guess preserving existing behavior makes sense
char: 'd', | ||
description: | ||
'Deploy the composite to the ceramic node, which will start indexing on the composite', | ||
default: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading the code correctly, I believe this is a behavior change. I'm pretty sure composite:from-model
does not index currently. I think this should probably default to false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. That should default false.
@@ -46,6 +46,10 @@ Create an encoded composite definition from GraphQL [Composite Schema](https://d | |||
|
|||
You can find a detailed guide on the creation of Composites [here](https://developers.ceramic.network/docs/composedb/guides/data-modeling/composites) | |||
|
|||
If updating your composite by specifying additional fields to filter on using the `createIndex` directive, run this | |||
command with `--no-deploy`. Your GraphQL definition will still be updated, but Ceramic will not attempt to re-index your |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will not attempt to re-index your composite
will not attempt to re-index the Models in your composite
@@ -117,6 +123,12 @@ available on the Ceramic Node that yor DApp connects to. You can find a detailed | |||
guide on Composites' deployment | |||
[here](https://developers.ceramic.network/docs/composedb/guides/data-modeling/composites#deploying-composites) | |||
|
|||
If updating your composite to add additional query fields, do not run this command. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did the language here get updated? I like the language you used for the create
command above (mod one small suggestion), can we re-use that?
Just want to add some context here https://forum.ceramic.network/t/devtools-composite-frommodels-does-not-support-filter/1304 |
@PaulLeCam @stbrody The gist is we want to enable 2 workflows:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
export async function createComposite( | ||
ceramic: CeramicClient, | ||
path: PathInput, | ||
deploy: boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a breaking API change, please set a default value or bump to v0.7 with docs updates.
packages/devtools-node/src/fs.ts
Outdated
@@ -36,12 +40,12 @@ export async function createComposite(ceramic: CeramicClient, path: PathInput): | |||
export async function readEncodedComposite( | |||
ceramic: CeramicClient | string, | |||
path: PathInput, | |||
index?: boolean, | |||
deploy: boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is misleading, reading from JSON always deploys the models to the node anyway so only the indexing request is optional, please keep as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't though. Composite create is the only command that creates (deploys) models to the node. readEncodedComposite
deploys in the same manner that the deploy command deploys. For consistency between commands and SDK, everything that deploys (indexes) now has a deploy parameter.
packages/devtools/src/composite.ts
Outdated
@@ -236,7 +236,7 @@ export type FromModelsParams = CompositeOptions & { | |||
* Whether to add the Models to the index or not. If `true`, the Ceramic instance must be | |||
* authenticated with an admin DID. Defaults to `false`. | |||
*/ | |||
index?: boolean | |||
index: boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep this optional.
No description provided.