Custom Data Types

rfernandez

Hi,
How do you suggest managing custom data types?
Example:
my_data_type -> possible values: value1, value2, value3
Then Form field with my_data_type will allow selection of one of these values.

To define this seems to be a common practice in coding.
I can do that using tables and perhaps collections which in the end will read from tables once, however I was wondering if r3 provides another way to do this?

Thank you!

gabriel

This would be a relationship, usually n:1. There have been some requests for ENUM types, that would bring something similar - but they would be much more limited than proper relationships.

I do not know how collections would come into play here, but maybe I misunderstand your request.

fmvalsera

Have you tried using presets? You must create a new relation holding the valid values and then link It from a column in the main relation.

Hope this helps!

rfernandez

Thank you both for your answers!
The question was preciselly oriented towards not having to define a table for holding a few static values, that won't probably change, or if so, will do once in a while.

@gabriel I mentioned the collections as a way or reading these values once when the user logs in and avoid executing the queries every time the values are required (that would be if I understood correctly how collections work; if it is not the case please tell me)

In the case of presets, will also work similarly by reading the values from tables. The advantage in this case will be that if it is an application you will replicate, these values will be already included, which is fine, just not my use case.

Again, thank you very much for you answers!!
I'll probably go for the tables plus basic CRUDs, and have the user load the values.
Only drawback is that I have a lot of these, but I'll have to work them with patience :-), and at the end I will have the most flexible scenario.

Warm regards!
Ricardo

gabriel

rfernandez The question was preciselly oriented towards not having to define a table for holding a few static values

Please state this beforehand so that I can understand where you are coming from :)

We decided against having another "simpler" way of offering this functionality (fixed values as single/multi selection in inputs), as then we would have multiple ways of achieving the same result; especially because this other way would be more limited (no filtering, no policies, no translations, and so on). And it would be really complicated, if you later needed to switch to the "proper" way (ie. relationships) when your requirements change.

rfernandez I mentioned the collections as a way or reading these values once when the user logs in and avoid executing the queries every time the values are required

Collections is a specific feature that works by querying relations - it would not have anything to do with optimizing access to ENUM field data. If we were to offer a feature like this, collections would be a bad idea, as these are controlled by app authors and they would then have to create these for every ENUM attribute.

rfernandez I'll probably go for the tables plus basic CRUDs, and have the user load the values.

Sorry but this negates the point of your request, in my view. Either you need simple values that are fixed (like an ENUM: value1, value2, value3, etc. as you described) - in this case your customer wants these values. Presets would do exactly that. They are even more flexible than ENUMs, as they can be updated if you want (s. protection settings on presets).

Or you do not want fixed values - then ENUMs would be worthless as these are fixed by definition.

rfernandez

Hi Gabriel,
I understand the decision, and respect it.

Collections are values read from relations and hold in memory (or some other sort of temporary storage)
Presets are records pre-loaded in the relations
Both are created by the app builder, and changing them will involve the application builder.
Am I right?

The negation of my initial point comes from the fact that there is no solution that does not involve relations (Collections involve relations, Presets involve relations), so I decided that if I'm going to have to create the relations, I will have the users load the initial values, and also give them the possibility of changing them afterwards.
In this way I delegate that responsibility to them.

Thank you!

gabriel

rfernandez Both are created by the app builder, and changing them will involve the application builder.

Collections are defined in the Builder (as is everything), but they can access any data - including data created by users. They have little to do with providing fixed values for lookups. They can be used for defaults though.

Presets can be fixed (ie. protected) but do not need to be so. Fixed presets are useful for data that must absolutely not change for your app to work correctly (states are a common example). Non fixed presets are also shipped with your app, but can be updated/deleted, depending on your settings.

If you need fixed records, such as for lookups, use protected presets. If you need default records, that can be updated/deleted by users, use non-protected presets. If you need fixed records, but want users to update preset record values, protect the preset but not the preset values.