🚀 Feature: Support for JSON and Datetime as attribute and visualizer for creating relations in the database !!

[arunavabasucom]

🔖 Feature description

👉In the admin panel, there is an option to select the DateTime value or when we last update the data in the document or create the document and also there is no option to add a JSON as an attribute. 😄
👉it is very handy if there is a visualizer to create relations between objects in the console.

🎤 Pitch

If these features are implemented that's very easy for users to create the APIs and used that.

👀 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?

• I have read the Code of Conduct

[Meldiron]

Regarding date time, we have been recently discussing such an attribute type, alongside updatedAt and createdAt attributes.

I will see what we can do about JSON. What would be the difference between a JSON attribute and a string one? You can do a method like JSON.stringify() on the client-side and store it in string attribute. Parsing afterwards would be as simple as JSON.parse().

Interesting idea about visualizing relations. We currently don't support native relations, but you can store IDs in string attributes. We do have a plan to add relations in the figure, but no ETA yet. Adding visualizer into Console is a cool idea tho, might be a great iteration.

[arunavabasucom]

That's great 👍 !! thanks

[Meldiron]

I can confirm we are now planning attributes that would support dates 🥳 With that, a plan to introduce automatic createdAt and updatedAt is in our mids. Make sure to join our Discord as we do weekly updates there. You can be the first one to know about progress of this feature 😎

[TorstenDittmann]

The DateTime Attribute got implemented and released with Appwrite 1.0.0 🥳

Thank you for your contribution 🙏🏻 You can read more here.

[johannesschobel]

Dear @TorstenDittmann ,
i guess, this issue / feature request is not completed. I think, some kind of object (JSON) type would be very handy! Can you please consider adding this feature as well?

[fliitor]

+1

[tremendus]

Not storing JSON is a huge omission, IMHO. Yes you can stringify as save, as @Meldiron mentioned, but since you have to set a max string length in your collection design and objects/arrays are flexible structures, knowing how long that string might be is very difficult.

[nimit2801]

Not storing JSON is a huge omission, IMHO. Yes you can stringify as save, as @Meldiron mentioned, but since you have to set a max string length in your collection design and objects/arrays are flexible structures, knowing how long that string might be is very difficult.

Exactly what I thought when I wanted to store maps coordinates for an event. I think JSON feature is really needed!

[been-there-done-that]

+1

[nimit2801]

please re-open this, we should discuss more on this.

[step135]

Looks like they ignore it.

[TorstenDittmann]

Not storing JSON is a huge omission, IMHO. Yes you can stringify as save, as @Meldiron mentioned, but since you have to set a max string length in your collection design and objects/arrays are flexible structures, knowing how long that string might be is very difficult.

I would set the max length of string attributes, but I see why this could be problematic especially displaying such data in UI.

[KevinHaendel]

The problem is not only that stringified JSONs are limited in character length, but a built-in type could also allow for searching/filtering within JSON attributes in the collection. MariaDB also natively supports JSON data types, as well as setting constraints to validate against JSON Schemas if needed.

I know that all of this could be accomplished by creating a new collection with the corresponding relations, but sometimes unstructured but still queryable data comes in very handy, especially for very dynamic data.