Creating an unbounded string

So, not familiar with GraphQL, but the docs here (and elsewhere) seem to indicate this should work:

type Profile @createModel(accountRelation: SINGLE, description: "model") {
  text: String!
}

However, when trying to compile I get

Error: Missing @string directive on string field text of object Profile

If I add a maxlength, it compiles fine

type Profile @createModel(accountRelation: SINGLE, description: "model") {
  text: String! @string(maxLength: 2500)
}

But I don’t want a max-length. It should be as long as it needs to be. From the samples it seems this should work, am I doing something wrong?

Hi,

All fields in ComposeDB models need to have strict validation, such as a max length for strings.
If you want something unrestricted, you could store the content on IPFS and store the CID of this content in a document using ComposeDB for example.

Understood. I’d rather not make this more complicated, so I’d rather keep it in Ceramic.

What’s the downside to setting an absurdly large max-length? (ie INT_MAX).

Is it possible to change the model in the future? If I set 5K chars, then decide I need 10K - what happens if I adjust this setting and try to re-deploy?

I guess the answer to changing the model is here: Future proofing composites

So I guess the only question is how large can I make this column?

Bump? This is moderately important to me, and I’m eager to get my next release out:

The question boils down to this - are these columns constant-sized? If I’m allocating a constant 5mb per entry, I might need to reconsider my approach.

You can set a high number as max length, but the max size of a single commit is 256 KB so you’ll hit Ceramic limitations if your field value is too long.

1 Like

Good to know - thank you! I assume that means the columns are variable-length, so as long as the sum of all the @string is less than 256KB ascii chars I will be fine (thats plenty) and I’m not going to explode my costs (again).

You’re welcome!
Yes the columns in the underlying DB should support variable length, and indeed if the sum of all the fields being set is lower than the commit size it should be no problem.
The commits includes signatures and other metadata so you wouldn’t have the full 256KB for the content itself, better check if you get close to this limit.