design of user selection data

[Scott Buchanan]

Greetings!  I have a conference app (lists sessions, hotel maps, etc.) from last year that I plan to enhance.

First, I am going to store the session details JSON in the backend services (as a file, not data type) instead of in the app.

ALso, I want to allow each user to select which sessions they will attend (checkbox on "all sessions" view) and also show a "my sessions" view of the selected items.  Obviously, I am going to store the selections separately.  My SQL background makes me want to add a data type to the backend services with columns such as userId and sessionId.  I read the documentation relations and offline storage, and I am left with questions

1. Can I join the JSON and data type using the relation support?

2. Since both of these are coming from everlive, I assume that when I set backend instance offline that both will be available, and when online the user selections will synchronize (user cannot change sessions JSON).  Does it make a difference how I construct the relation is order to persist changes to the users session selection when offline?  That is, should the selection table be primary and relate the session list to it (or would that give me trouble to display non-selected items?) or should the session list be primary and relate the selections to it (makes sense but not sure how to save selections then...)

I have cloned the deliveries app, and I'm sure it will be helpful, but it seems a bit simpler (only one table).

Thanks,
Scott

[Martin]

Hi Scott,

From your description I assume you want to use Telerik Platform Content Types but store your data in a JSON file instead of the supported field types.

1. Using JSON file instead of supported field types:

• You will not be able to use querying which includes basic operations like filtering, sorting, paging and other operations on the stored data which you will need to display filtered data (only the sessions of a user for example).

• Relations is not supported for JSON files but only for supported field types.

• Offline support would work, as all the data is stored as a JSON and parsed afterwards.

2. Design considerations - multiple content types/tables. Telerik Platform uses a NoSQL database and there are some limitations that need to be considered when using relations:

• Currently you can filter only on the Content Type you are making a request on and not on the expanded one.
• Furthermore, there is a limitation on the maximum result item count of 50 items (for performance reasons) which eliminates the possibility to get all expanded data and filter it on the device (instead with a query on the server).

In general a NoSQL database is quite different from a relational database mainly in these cases:

• in a NoSQL database data de-normalization is preferred (in relational it is the opposite) - The de-normalization allows you to go with the strategy of storing (embedding) large amounts of related data in a single rich document.  This alleviates you of the chore of creating many content types with relations between them. You may still create relations, although they only makes sense when imposed by the client app's data access patterns and their frequency or when you need to set up specific permissions for a given content type or content type items.
• Optimize your schema for the most frequent use cases - use only one Content Type instead of two - this will create duplicate data but will lead to faster queries.

This said, you may consider:

• to use the supported content types of Telerik Platform - thus you will be able to use all the functionality of Telerik Platform and the JavaScript SDK.
• to use only one Content Type and add a field in every session holding an array of users that have selected the session instead of creating a separate content type holding a "sessionId" and "userId". ​Thus you will reduce the usage of relations and will not have to comply with the limitation they introduce.

Let me know if this has helped you.

Regards,
Martin
Telerik by Progress

 

 

[Scott Buchanan]

Martin,

 

Thank you - that is very good data.  

Just to be clear, the JSON file (containing the conference sessions) is currently a File, not a Type.  I understand that if the session data were a Type, and I also stored the user selections in a Type, this would be the the preferred approach.

The primary reason for not creating a session Type is that no one wants to re-type / cut+paste all of the entries (the JSON file was exported from the SQL database).  I am not aware of a method to upload data to populate a Type - is there a method (short of writing an app!)?

Best,
Scott

[Anton Dobrev]

Hello Scott,

Indeed, it is recommended to create the items as records in a content type and do not use them from a file.

You can easily do this with either using the REST API or the client SDKs. You can read more about this here. For example, use the endpoint for creating multiple items and POST a request to it with a tool like Postman, Fiddler, Charles, Paw. You can get the items from the JSON file and post them with the body of the request.

After the items are created you will be able to work with the data from your app as explained here.

Regards,
Anton Dobrev
Telerik by Progress