Tiddler field serialization question

How do I know what a particular field is supposed to look like, either on the client or the server? In MWS, we’ll probably need to parse certain fields and save them in an index, but all fields need to be saved as a string. Does the server need to do any parsing, or can we trust the client to give us a correctly formatted field? I guess the tags field is pretty obvious, and we could expect that field to be an array, but how far do we open that can of worms? It seems like there is no defined format for fields other than that they all end up as strings in a file eventually. If we save everything as a string in the database, we could export those strings verbatim into a .tid file if we need to, but even there we would need to determine whether to use a header or a meta file. But I guess that is simple enough that we could just look at the type field and handle it based on that. We can’t really support custom types on the server, though, which might be annoying for some people when they don’t see exactly what they expected in their export folder. I don’t know, thoughts? @jeremyruston @pmario , or anyone else familiar with this problem.

Usually we can trust the TW app, but we can not trust the data from every client. The data can be sent to the server by any program that knows the API.

I think tags can be used for indexing by default. In the client tags are stored as arrays. If they are requested, they are serialised to TitleLists

I think that’s right. – I did not have a closer look a the new MWS implementation.

But the “first iteration” from Jeremy basically did store every field separately. The SQL queries then did assemble tiddlers → bags → recipes.

You may have a closer look at a new discussion at GH: Using New UUID v7 as a Tiddler ID for MWS Related Data Storages which I did create some time ago.

It is only slightly related to your question. But it should have potential to improve the MWS database indexing if “created” date is a thing.

Just some more thoughts.