Skip to content
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

🚀 Feature: Add Text attribute #3386

Open
2 tasks done
senguendk opened this issue Jun 16, 2022 · 9 comments
Open
2 tasks done

🚀 Feature: Add Text attribute #3386

senguendk opened this issue Jun 16, 2022 · 9 comments
Labels
enhancement New feature or request product / databases Fixes and upgrades for the Appwrite Database.

Comments

@senguendk
Copy link

🔖 Feature description

Would it be possible to add back a text attribute that allows for arbitrarily long strings? Most databases provide a native type for this. I feel like Version 0.12 made a step backwards in that regard.

🎤 Pitch

I am creating a cms for scientific articles. Some articles are very long. Since it is not possible to change the settings of an attribute easily once it has been created, it is really tough on deciding on a string size for the content string attribute.

👀 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

@Meldiron
Copy link
Contributor

Hey there 👋

Under the hood, we currently use MariaDB and its data types. You can refer to this piece of the code to see what type we use for specific lengths: https://github.com/utopia-php/database/blob/main/src/Database/Adapter/MariaDB.php#L1182-L1208

As you can see, even TEXT in MariaDB has some limitations regarding length. If you want to be extra safe, I would recommend LONGTEXT by setting size to 16777216. That will under the hood create A LONGTEXTTEXT column with a maximum length of 4,294,967,295 or 4GB ( 2^32 - 1 ) characters..

Regarding version 0.12, the limit was still there, it was just not visible. I believe we used TEXT data type, which is limited to 64kB.

@Meldiron
Copy link
Contributor

Going back to the feature request, do you think UI changes would be enough to address this problem? Would it be better understood if we showed these breaking points for data types in the UI?

@senguendk
Copy link
Author

Hey! Man, you guys are quick to respond! Thank you for that!

Yes, that would be great. Maybe some comment or info pop up would be nice. Maybe putting that information in the documentation would be enough also.

@Meldiron Meldiron added the product / databases Fixes and upgrades for the Appwrite Database. label Jun 22, 2022
@folkevil
Copy link

folkevil commented Nov 17, 2022

+1 for this feature, text/json attribute is often to use , as I see currently I can't create attribute with text/json in dialog, and documentation too.

@shatanikmahanty
Copy link

Since arbitrarily long strings won't be supported due to technical constraints, will it be possible to modify size of strings later?

@narnau
Copy link

narnau commented Jun 15, 2023

Since arbitrarily long strings won't be supported due to technical constraints, will it be possible to modify size of strings later?

+1. I didn't find how to modify the size of a string attribute.

@gewenyu99
Copy link

Since arbitrarily long strings won't be supported due to technical constraints, will it be possible to modify size of strings later?

I think the concern is the massive performance impact of doing this. The way data is laid out physically on hard-discs will mean you'd have to shift huge amounts of data in big DBs to change size of a string attribute.

You might be better off creating a new attribute, writing a script to copy existing data to new attribute, and deleting the old attribute.

But this is still and interesting suggestion that we'll look into <3

@stnguyen90 stnguyen90 added enhancement New feature or request and removed feature labels Mar 20, 2024
@Sun3
Copy link

Sun3 commented Apr 15, 2024

Any updates on allowing the size of a Text field to be increased?

Thanks.

@gewenyu99
Copy link

@Sun3 We're still recommending the Expand Contract pattern for now.

Updating a field directly is not a great idea because how heavy a [ALTER COLUMN](https://www.w3schools.com/sql/sql_ref_alter_column.asp) tends to be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request product / databases Fixes and upgrades for the Appwrite Database.
Projects
None yet
Development

No branches or pull requests

8 participants