Creating field with datatype "TEXT" on api causes error

[Lapsus]

Bug Report

Steps to Reproduce

1. Create a new database table with an id column/primary key and a column "position" as longtext. Table should not be managed by Directus yet.
2. Fetch collection data for the new table via API.
3. Merge the fetched data to have the collection managed with Directus.
4. Merge the field definition fetched from the API to make column "position" use the "Map" interface.

Expected Behavior

Collection and fields are created properly, as the collection is now managed, and the fields provide interface information.

Actual Behavior

Error: Code: 403 - field "position" does not support length

Other Context & Screenshots

Other interfaces like status, text or date work well that way. Fetching the collection info via API, modifying the data to make the collection managed and setting the fields to the required interfaces. But it failes for "Map", or "Advanced WYSIWYG".

If length is not used by the longtext datatype, it should either be not provided when fetching collection data or it should be ignored when creating the field. At least in my humble opinion.

Or is this the wrong approach?

[Lapsus]

I just provided some more details to reproduce the problem.
If i remove the length attribute before passing the information back it works as expected.
So if the length is not required for the datatype, it should be ignored or removed from the filed when fetching the collection information via the api. (in my humble opinion of course).

[wellingguzman]

Hey @Lapsus, this is not a bug, it's a expected behavior. The reason there's an error, it's to warn that no matter the length they provide it won't be useful, we could silently avoid this, but then it could cause issues when the user assumes the length was accepted, when it was actually ignored.

That data is provided as information to let the user know how many character the field takes.

[Lapsus]

Hmm but it seems quite confusing to me ,if the data structure for the field is different depending on the datatype.

Maybe this is an issue for the documentation then? As far as i have seen, there is no documentation on how the fields have to be defined depending on datatype/interface etc. Or did i miss that? I think i remember having read some note on fields, but no clear definition on what has to be defined or is optional for the different datatypes.

[rijkvanzanten]

But it failes for "Map", or "Advanced WYSIWYG".

It sounds like my that the application might wrongly send the length value, even though it's not being used. @wellingguzman this might actually be an issue on the application side of things, not the API.

[Lapsus]

I am fetching and sending back to the API without using the APP.

if that helps. i am creating a setup script that fetches from the collection endpoint and modifies the fetched data to make certain collections managed and to setup the fields according to an external configuration. The modified data structure is then sent back to the API endpoint.

[rijkvanzanten]

Ahh I see. I think the API might return length: null for those fields, but then throws a warning if you send length: null.

I suppose the API should ignore if length: null is send for TEXT fields. I think it should return the error when a length is provided that something not null, f.e. length: 200 as that implies that the user made a mistake

[benhaynes]

So is this working as expected? Should we update the Docs accordingly and then close this?

[wellingguzman]

It's working as expected, It's a confusion, or missing information what that means. There are some mysql types that doesn't require length, even though some return an actual length, such as TEXT.

Ignoring length can be confusing as well, when the field doesn't even allow it.

I prefer removing the length from these data types than ignoring them when they exists.

[rijkvanzanten]

But that means that the API won't accept it's own output as it's input. If the API is returning length: null for TEXT type fields, it should accept length: null as input for those fields as well

[wellingguzman]

I believe Input shouldn't reflect output, or be 100% compatible. While the field has length, the length cannot be changeable, that's why is not allowed in the input. returning null could means it has no length.

We can discuss what we can do here to avoid the confusion.

I will close this as this is not a bug nor a feature request.